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Abstract 

In  the  context  of  evolving  missions  and  radical  changes  in  the  strategic  and  operational 
environments  in  the  DoD,  the  ability  to  understand  the  rationale  behind  key  decisions  and 
evaluate  the  repercussions  of  changes  in  underlying  assumptions  and  requirements  will  be 
very  valuable  to  key  decision  makers.  In  this  research  we  propose  to  develop  models  and 
mechanisms  necessary  to  provide  comprehensive  Design  Records  (DR)  that  help 
understand,  evaluate  and  reuse  critical  decisions  in  complex  problem  solving  situations  such 
as  the  specification  and  development  of  C4I  systems.  Based  on  theoretical  and  empirical 
studies,  model(s)  to  represent  critical  components  of  the  rationale  behind  critical  decisions 
have  been  developed.  Mechanisms  designed  to  support  the  needs  of  various  stakeholders 
involved  in  the  decision  making  process  are  discussed.  A  prototype  decision  support  system 
that  incorporates  these  models  and  mechanisms  to  support  the  capture  and  use  of  design 
records  is  discussed  with  examples  drawn  from  the  context  of  the  design  of  information 
products.  Additional  examples  drawn  from  various  system  development  scenarios  are  also 
discussed  in  Appendix  I. 
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1.  Introduction 


Organizational  memory  provides  the  means  by  which  organizational 
knowledge  from  the  past  can  influence  the  present  organizational  activity.  It  is  stored 
information  from  an  organization’s  history  that  can  be  brought  to  bear  at  present 
decision.  Recent  literature  emphasizes  the  importance  of  mechanisms  to  capture  and 
manage  rationale  in  situations  involving  large  number  of  participants  involved  in 
complex  organizational  processes  like  large-scale  systems  development  [8].  In 
collaborative  activities  involving  a  large  number  of  participants,  each  having  a 
different  set  of  goals  and  priorities,  maintaining  a  comprehensive  history  can  be 
invaluable.  Such  a  history  is  an  important  component  of  OM  and  includes  various 
types  of  memory  which  has  been  called  Group/team  memory,  design 
rationale/discussion  memory,  and  project  memory.  In  this  report,  we  take  this  limited, 
task  specific  view  of  Organizational  Memory,  recognizing  that  a  comprehensive 
organizational  memory  includes  information  retained  by  individuals,  culture, 
transformations,  structures  and  ecology. 

A  variety  of  stakeholders  involved  in  organizational  decision  processes  bring  together 
their  often  unique  viewpoints  and  expertise.  These  range  from  top  management 
providing  inputs  on  the  nature  of  the  problem  and  its  impact  on  the  organizational 
goals,  to  middle  managers  who  help  articulate  objectives  and  constraints,  to  lower 
level  workers  that  implement  them.  In  contexts  where  tightly  integrated  decision 
processes  across  functional  boundaries  cannot  be  easily  developed  and  implemented, 
organizational  memory  that  provides  a  loose  coupling  between  relevant  decision 
situations  can  greatly  enhance  shared  understanding  across  these  boundaries. 
Coordination  among  the  various  stakeholders  which  is  critical  to  success  can  be 
facilitated  with  organizational  memory  that  integrates  their  various  perspectives.  A 
basic  premise  in  our  work  is  that  for  each  of  the  stakeholders  involved  in  such 
processes,  some  useful  support  can  be  provided  by  recording  in  some  structured 
fashion  relevant  portions  of  organizational  memory. 

Recent  studies  confirm  that  capturing  organizational  memory  is  especially  important 
in  large-complex  activities  for  the  following  reasons: 

•  The  context  in  which  key  decisions  are  made  will  be  lost  when  different  teams  are 
engaged  in  various  aspects  of  the  organizational  process. 

•  Critical  errors  are  commonly  made  in  formulation  and  resolution  of  decisions,  but 
they  are  often  unnoticed  in  the  absence  of  comprehensive  organizational  memory 

•  In  the  absence  of  reliable  organizational  memory,  work  groups  engage  in  repetitive 
discussion  and  resolution  of  the  same  issue 

•  When  stakeholders  with  differing  expertise,  perspective  and  viewpoints  are 
involved,  key  decisions  are  often  misunderstood  and  misinterpreted 

Recent  research  argues  that  complex  decision  making  situations  involve  a 
constantly  changing  environment  and  preferences.  Further,  these  situations  are 
also  characterized  by  incomplete  and  even  inaccurate  information.  In  such 
complex  decision  situations,  a  comprehensive  organizational  memory  of  the 
context  in  which  decisions  are  arrived  at  and  the  ability  to  understand  and  analyze 
its  implications  when  it  changes  will  be  extremely  helpful  The  need  to  capture  and 
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reason  with  the  information  regarding  the  context  is  even  more  pronounced  when 
the  decision  making  includes  participants  from  various  functional  domains.  OM 
that  provides  the  ability  to  modify  and  manipulate  decisions  in  response  to 
changing  requirements  and  assumptions  are  valuable  in  diagnostic  problem 
solving. 

A  major  challenge  in  this  research  is  to  represent  relevant  parts  of  OM  to  facilitate 
shared  understanding  and  use  of  multiple  stakeholders  in  complex  problem  solving 
activities.  In  this  proposal,  we  focus  on  capturing  and  using  the  rationale  behind 
critical  decisions  (called  design  records)  1 .  In  this  section  we  examine  the  nature  of 
such  activities  to  identify  the  characteristics  of  OM  that  must  be  captured.  We 
highlight  the  implications  for  the  representation  and  acquisition  of  OM.  The 
capabilities  for  a  prototype  Organizational  Memory  System  (OMS)  that  facilitates  the 
acquisition,  maintenance  and  use  of  OM,  automated  tools  for  supporting  the  needs  of 
various  stakeholders  will  be  developed  in  this  research. 


2.  Characteristics  of  a  Design  Records  (OMS) 


2.1  Managing  Conflicts 


Complex  decision  making  situations  involve  a  multitude  of  trade-offs  across  and 
within  functional  domains.  When  multiple  stakeholders  participate  in  collaborative 
activities,  they  can  disagree  on  a  wide  range  of  issues  due  to  differences  in  goals,  the 
information  available,  and  the  understanding  of  the  task.  Some  conflicts  may  arise 
when  stakeholders  differ  in  their  respective  interests,  whereas  others  may  be  caused  by 
the  fact  that  different  parties  in  a  team  can  bring  to  bear  different  and  often  incomplete 
views  of  the  task. 

Conflicts  arise  even  when  stakeholders  do  not  differ  in  their  respective  utilities,  but 
simply  because  they  offer  multiple  cognitive  perspectives  on  the  problem.  Such 
conflicts  are  called  judgement  conflicts  or  cognitive  conflicts  and  they  “play  a  major 
role  in  a  number  of  models  of  decision-making”.  Judgement  conflicts  can  arise  when, 
even  in  the  same  domain,  different  experts  use  different  set  of  variables  to  perform 
their  tasks.  Successful  collaborative  activities  require  a  co-evolution  of  personal 
understanding  of  the  participants  and  the  shared  understanding  of  the  group.  This 
problem  is  exacerbated  when  the  participants  are  interested  in  understanding  the 
context  or  history  of  their  task  situations.  Therefore,  it  is  essential  to  explore 
mechanisms  to  manage  judgement  conflicts  so  that  relevant  information  can  be 
captured  in  OM  to  facilitate  shared  understanding. 

The  management  of  judgement  conflicts  can  be  thought  of  as  an  iterative  process  of 
convergence  at  two  levels:  a  collective  reconceptualization  of  the  task,  and  convergence  with 
respect  to  the  importance  of  different  variables  used  in  the  solution  space.  However,  as 
research  on  expertise  and  on  human  infonnation  processing  suggests,  this  is  difficult  because, 


1  The  terms  organizational  memory,  design  records  and  decision  rationale  are  used  interchangeably 
in  this  report. 
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in  large  part,  human  decision  behavior  is  implicit  and  automatic,  and  thus  difficult  to  articulate 
and  convey.  In  addition,  certain  types  of  information  are  often  not  articulated  at  all  because 
they  are  perceived  as  being  "obvious"  within  a  particular  functional  domain  (whereas  they  may 
not  be  obvious  at  all  to  participants  from  other  domains). 

The  need  to  support  sensemaking,  a  process  of  negotiation  and  construction  of  a 
mutually  shared  agreement  of  what  causal  linkages  and  outcome  preferences 
constitute  a  confusing  event,  is  well  recognized.  They  argue  for  supporting  the 
strategies  of  action,  triangulation,  affiliation,  deliberation  and  contextualization. 
Action  can  be  facilitated  when  the  support  system  can  be  used  in  the  context  of  actual 
work  rather  than  in  an  isolated  decision  support  facility.  Triangulation  can  be 
facilitated  by  providing  access  to  diverse  information  sources  in  a  variety  of  formats. 
Affiliation  can  be  facilitated  with  aids  for  building  shared  interpretation.  Providing 
access  to  group  memory  consisting  of  artifacts  produced  during  meetings  can  facilitate 
deliberation.  Contextualization  can  be  aided  by  providing  access  to  context  in 
“constructing  causal  linkages,  outcome  preferences,  and  shared  interpretations”. 
Recent  work  also  warns  against  creating  support  systems  that  increase  meeting  pace, 
decrease  social  interaction,  prevent  emergent  approaches,  and  isolate  participants  from 
events,  because  they  impede  sensemaking. 


2.2  Implications  for  Design  Records  OMS 


Contents  of  OM.  It  is  suggested  that  complex  tasks  such  as  those  involving  the 
deliberation  process  of  assumption  surfacing,  information  exchange  and 
reconceptualization  be  supported  with  appropriate  cognitive  artifacts  for  representing 
thought  and  exchanging  ideas.  Researchers  in  social  judgment  theory  have 
conceptualized  cognitive  feedback  as  a  generalized  term  for  cognitive  artifacts 
appropriate  for  managing  judgement  conflicts.  An  important  issue  for  the 
development  of  OM  is  the  identification  of  information  that  should  be  provided  as 
part  of  cognitive  feedback.  Cognitive  maps  characterizing  the  context  of  a  decision 
situation  have  been  used  to  address  this  issue.  A  dependency  mechanism  would 
maintain  interdependencies,  and  thus  provide  information  about  the  task  environment. 
This  would  help  a  participant  become  familiar  with  the  relevant  aspects  of  other 
functional  domains.  Finally,  the  system  could  help  in  reconceptualizing  the  solution 
space  by  providing  feedback  on  assumptions  that  are  in  conflict. 


Effective  integration  of  various  viewpoints  can  be  accomplished  through  the  use  of 
three  design  principles:  flexibility  in  capturing  and  presenting  information,  ownership 
of  representations,  and  maintaining  context.  At  the  individual  level,  context  -  as  often 
driven  by  the  functional  domain  -  is  present  in  an  implicit  fashion.  However,  this 
context  is  often  lost  in  the  transition  to  the  interpersonal  or  collective  level,  when 
domains  are  traversed.  The  effectiveness  of  OMS  can  be  enhanced  if  they  are 
designed  to  provide  and  maintain  context.  For  example,  the  ability  to  bring  otherwise 
implicit  assumptions  to  the  surface  could  be  a  useful  way  to  maintain  context  in  the 
transition  between  levels. 
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In  summary,  the  above  discussion  suggests  that  components  of  OM  should  include 
rich  contextual  information  not  only  to  provide  detailed  viewpoints  of  individual 
decision-makers,  but  also  to  identify  interdependencies  among  differing  perspectives 
and  viewpoints.  Providing  such  comprehensive  traceability  (which  we  define  as  the 
capability  to  relate  an  OM  component  to  its  sources,  refinements  and  use)  will  greatly 
enhance  the  usefulness  of  OM. 


Representation  of  OM.  An  important  issue  brought  out  by  the  above  discussion  is 
the  choice  of  representation  for  OM.  Organizational  memory  can  be  represented  at 
different  levels  of  formality,  from  "mathematically"  formal  representations  (e.g., 
transformations  that  can  formally  derive  one  design  state  from  another  in  a  formal 
specification  based  systems  development  environment)  to  very  informal 
representations  (e.g.,  design  notebooks  that  record  the  progression  of  steps  and  other 
relevant  information  in  natural  language). 

Formal  representations  of  OM  facilitate  automated  reasoning.  In  large  complex 
organizational  processes  where  the  size  and  complexity  of  OM  can  grow  rapidly, 
facilities  for  automated  reasoning  can  be  very  valuable.  However,  formal 
representations  of  OM  have  several  limitations.  They  are  feasible  only  in  domains  that 
have  formal  domain  models,  and  in  tasks  where  the  semantics  are  well  defined.  The 
domain  knowledge  needed  to  create  formal  representations,  thus,  is  not  readily 
available  in  most  situations.  Another  important  consideration  in  the  choice  of 
representation  is  that  much  of  the  informal  information  does  not  lend  itself  to  formal 
representation. 

Informal  representations,  though  not  amenable  for  automated  reasoning,  have  some 
advantages.  Much  of  the  OM  can  be  more  easily  captured  through  informal  means. 
Second,  informal  representations  enable  the  retention  of  information  in  its  most 
complete  form,  thereby  facilitating  the  creation  of  thick  descriptions. 

In  summary,  then,  formal  and  informal  representations  of  OM  complement  each  other 
in  their  respective  strengths  and  weaknesses.  Informal  representations  are  easy  to 
capture,  whereas  formal  representations  can  be  manipulated  by  well-defined  reasoning 
facilities. 


2.3  Common  Approaches 


Several  models  and  systems  that  support  the  acquisition  and  use  of  OM  have  been 
developed  recently.  Systems  such  as  gIBIS  (Conklin  and  Begeman,  1988)  and  others 
that  are  inspired  by  it  (e.g.,  IBE  [16]),  advocate  the  representation  of  informal 
information  as  a  part  of  a  comprehensive  OM.  These  systems  provide  a  hypertext 
interface  to  the  IBIS  model  and  are  constrained  by  the  limitations  of  IBIS  such  as  the 
lack  of  representation  of  inputs  and  outcomes  of  argumentation.  In  contrast,  we  argue 
for  a  generic  framework  that  can  be  tailored  to  support  a  variety  of  models  such  as 
IBIS  and  its  extensions  (such  as  REMAP  that  overcome  some  of  its  limitations). 

A  few  proposals  for  capturing  the  history  of  complex  organizational  processes  have 
been  made  (Rarnesh  and  Dhar,  1992).  This  research  emphasizes  the  need  for  access  to 
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history  of  organizational  decisions.  Our  work  intends  to  extend  the  scope  and  nature 
of  process  knowledge  captured  so  that  a  variety  of  stakeholders  can  be  supported  in 
different  ways  in  their  tasks.  We  argue  for  a  generic  framework,  so  that  a  rich  history 
of  knowledge  about  decisions,  various  alternatives  that  may  have  been  considered  and 
discarded,  the  organizational  context  which  lead  to  various  components  of  the 
scenarios  and  rationale  can  be  captured  and  reasoned  with. 

Many  groupware  systems  (such  as  GroupSystems,  VisionQuest)  focus  primarily  on 
capturing  informal  knowledge.  OMS  such  as  Constellations  facilitate  access  to 
informal  knowledge  by  chunking  multimedia  information.  The  need  to  integrate 
informal  information  in  hypertext  with  formal  models  in  model  management  has  been 
suggested  in  the  literature.  Our  work  takes  a  more  comprehensive  approach  to  dealing 
with  informal  information  advocating  the  creation  of  formal  models  to  facilitate  better 
integration.  Further,  instead  of  maintaining  a  passive  history  (as  in  IBIS  and  QOC), 
our  focus  is  on  providing  intelligent  support  by  maintaining  an  active  history.  Our 
approach  provides  the  opportunity  to  expand  the  scope  of  integration  to  include  much 
fuzzier  contextual  information  and  formalizing  this  information  whenever  feasible. 
We  suggest  a  much  tighter  integration  of  formal  and  informal  components  of  OM. 
Such  systems  can  be  integrated  with  our  system  to  provide  fine-grained  access  to 
informal  OM.  Also,  as  the  capture  and  use  of  OM  can  add  significant  overhead  to  the 
stakeholders  using  them,  an  OM  system  should  provide  automated  reasoning  to 
support  various  stakeholder  needs. 

2.4  Our  approach 


A  major  challenge  in  this  research  is  to  represent  relevant  parts  of  design  records  to 
facilitate  shared  understanding  and  use  of  multiple  stakeholders  in  complex  problem 
solving  activities.  An  important  feature  of  our  technical  approach  is  that  we  suggest 
that  components  of  design  records  should  include  rich  contextual  information  not  only 
to  provide  detailed  viewpoints  of  individual  decision-makers,  but  also  to  identify 
interdependencies  among  differing  perspectives  and  viewpoints.  Providing  such 
comprehensive  traceability  (i.e.,  the  capability  to  relate  a  critical  decision  its  sources, 
refinements  and  use)  will  greatly  enhance  the  usefulness  of  design  records. 

Further,  we  propose  the  integration  of  formal  and  informal  representations  of  design 
records  as  they  complement  each  other  in  their  respective  strengths  and  weaknesses. 
Informal  representations  are  easy  to  capture,  whereas  formal  representations  can  be 
manipulated  by  well-defined  reasoning  facilities.  We  provide  a  generic  framework,  so 
that  a  rich  history  of  knowledge  about  decisions,  various  alternatives  that  may  have 
been  considered  and  discarded,  the  organizational  context  which  lead  to  various 
components  of  the  scenarios  and  rationale  can  be  captured  and  reasoned  with.  Also,  as 
the  capture  and  use  of  design  records  can  add  significant  overhead  to  the  stakeholders 
using  them,  we  have  developed  a  prototype  decision  support  system  that  provides 
automated  reasoning  capabilities  to  support  various  stakeholder  needs.  These  include 
facilities  for  the  maintaining  the  integrity  of  the  knowlegebase  using  a  reason 
maintenance  system,  mechanisms  to  maintain  dependencies  among  various 
components  of  decision  records,  and  making  deductive  inferences. 
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3.  Development  of  Information  Products:  An  Example 


In  this  report,  we  describe  the  need  for  representing  and  using  design  records 
and  illustrate  the  functionalities  of  our  decision  support  environment  through  an 
example.  We  have  chosen  the  design  of  information  products  as  the  example  since  it 
highlights  all  the  major  issues  discussed  in  the  earlier  sections. 

Design  is  a  knowledge  intensive  activity,  often  carried  out  by  distributed 
teams.  For  example,  information  products  are  characterized  by  unusual  economics  of 
production,  need  to  be  delivered  within  highly  compressed  time  frames,  have  short 
life  cycles,  perish  in  value  quickly  and  have  marginal  production  costs  approaching 
zero,  after  the  first  unit.  Such  products  are  often  developed  by  cross-functional  and 
trans-institutional  teams  that  are  often  geographically  distributed.  Recent  research 
recognizes  the  importance  of  capturing  comprehensive  history  behind  the  design 
decision  making  in  such  dynamic  situations.  Based  on  the  characteristics  and 
challenges  faced  in  design  activities,  we  identify  the  requirements  for  a  decision 
support  system  (DSS)  for  design  decision  making.  Using  these  goals,  we  have 
developed  a  DSS  that  supports  linking  of  artifacts  to  processes,  flexible  interaction 
and  hypermedia  services,  distribution  annotation  and  authoring  as  well  as  providing 
visibility  of  artifacts  as  they  change  over  time. 

Widespread  penetration  of  the  Internet  has  led  to  an  unprecedented  increase  in  the  trade 
of  information  products.  Information  products  consist  of  a  highly  interdependent 
package  of  information  that  is  primarily  intangible  in  nature.  This  implies  that  they  can 
not  be  physically  inspected  before  purchase  (Koppius,  1999),  and  that  traditional  ways 
of  trading  them  have  no  advantage  over  trading  them  electronically  (Koppius,  1999). 
The  Internet  has  provided  a  channel  for  the  distribution  and  trade  of  such  products  at 
low  overhead  costs  (Koppius,  1999;  Shapiro  and  Varian,  1998).  When  distributed  over 
such  a  medium,  their  variable  cost  or  production  and  distribution  approaches  zero  as  the 
product  has  no  physical  form  unlike  retail  packaged  software.  However,  due  to  their 
intangible  nature,  information  product  markets  face  severe  competitive  challenges  in 
comparison  to  tangible  products  (Koppius,  1999;  Shapiro  and  Varian,  1998).  Shapiro  et 
al.  (1998)  caution  that  the  low  economic  cost  of  reproduction  of  such  products  also 
makes  them  economically  lesser  viable.  If  left  to  the  market  place,  the  price  of  an 
information  product  will  be  low  due  to  the  low  marginal  cost  of  reproduction  of  that 
product  (Shapiro  and  Varian,  1998). 

In  the  post-industrial  era,  knowledge -based  activities  of  organizations,  including  IS 
organizations,  are  becoming  the  primary  internal  junction  of  firms  (Davenport,  1993; 
Quinn  et  al.,  1996).  More  of  an  organization’s  competencies  will  center  around 
managing  knowledge  and  knowledge  work  surrounding  the  development  of  its  products 
and  services,  and  this  will  determine  most  productivity  gains  that  occur  (Davenport  et 
al.,  1996)  in  the  information  product  development  (IPD)  processes.  Development  of 
information  products  is  a  knowledge  intensive  activity  (Fielding  et  al.,  1998;  Robillard, 
1999;  Zack,  1999).  As  a  firm  gains  experience  through  the  development  of  information 
products,  much  of  the  lessons  learned  still  remain  captured  as  information  (Fielding  et  al., 
1998;  Robillard,  1999;  Zack,  1999)  and  do  not  get  applied  i.e.  converted  to  knowledge 
(Drucker,  1993).  Therefore,  it  is  critical  to  be  able  to  manage  and  reapply  lessons  learned  and 
design  decisions  made  in  earlier  projects  in  similar  contexts  in  order  to  keep  fthe  product 
competitively  viable. 
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3.1  Defining  Information  Products 

An  information  product  is  defined  as  a  highly  interdependent  package  of  information  (Fielding 
et  ah,  1998).  Software  engineering  products,  CD-ROM  databases,  and  Web  content  are 
examples  of  such  products  (Meyer  and  Zack,  1996;  Robillard,  1999).  A  more  restrictive  is 
provided  by  Shapiro  et  al.  (1998),  where  they  categorize  information  products  as  those 
products  that  are  capable  of  being  distributed  in  digital  form.  In  economic  tenns,  the  fixed 
costs  involved  in  producing  an  information  product  are  very  high  and  the  variable  costs  are 
relatively  low  (Shapiro  and  Varian,  1998).  This  factors  necessitate  differentiation  among 
information  products,  as  perfect  competition  can  spell  disaster  for  the  producer(s)  in  the 
markets  for  that  product  (Meyer  and  Zack,  1996;  Shapiro  and  Varian,  1998). 

3.2  IPD  as  a  Knowledge  Intensive  Activity 

Information  product  markets  are  dynamic  in  terms  of  growth  and  the  pace  of  new  product 
introduction  (Meyer  and  Zack,  1996).  As  teams  in  an  organization  engage  in  the  development 
of  new  products  and  services,  the  underlying  rationale  used  to  make  decisions  at  various  points 
in  the  design  process  need  to  be  effectively  captured  and  reused  (Wong,  1988;  Yglesias,  1993) 
to  provide  support  for  decisions  in  later  projects  or  in  the  production  of  subsequent  product 
versions  (Tiwana  and  Raven,  1999).  This  necessitates  a  closer  examination  of  the  role  of 
knowledge  in  the  design  process. 

Davenport  and  Prusak  (1998)  point  to  the  subtle  difference  between  knowledge  and 
information,  defining  knowledge  as  actionable  information.  Drucker  (1993)  also  introduces  the 
concept  of  productivity  of  knowledge,  which  he  indicates  is  the  deciding  factor  in  the 
competitive  position  of  a  company.  Drucker  further  cautions  that  knowledge  is  productive  only 
if  it  is  applied  to  make  a  difference  in  the  processes  or  tasks  at  hand.  This  requires  systematic 
and  organized  application  of  knowledge  to  enhance,  validate  and  apply  existing  knowledge 
(Drucker,  1993).  An  excellent  characterization  of  the  level  of  knowledge  that  is  applied  to 
decision  making  processes  is  provided  by  Bohn  (1994).  As  developing  organisations  move  up 
on  this  process  knowledge  scale,  developing  information  products  moves  up  from  a  learning 
process  to  a  systematic  process  that  uses  insights  gained  from  the  development  of  previous 
versions  of  such  products  (Bohn  (1994)  describes  this  as  process  capability).  Recent  research 
in  production  management  in  the  publishing  and  design  stream  points  to  this  transition  from  a 
craft  (identified  by  stages  1-4  in  Bohn's  (1994)  process  knowledge  framework)  to  process 
orientation  (as  characterized  by  stages  5  through  8  in  Bohn’s  (1994)  framework)  (Bellander, 
1998).  Bellander  (1998)  notes  that  this  transition  from  a  handicraft -based  industry  to  a  process 
industry  is  not  an  easy  transition. 

New  information  product  development  often  involves  cross-functional  teams,  where  different 
participants  join  a  team  with  differing  viewpoints.  Such  teams  are  often  characterized  by 
participants  who  achieve  a  high  level  of  at-stakeness  and  synergy  from  their  interactions 
(Jassawalla  and  Sashittal,  1998)  with  other  team  members.  Fielding  et  al.  (1998)  suggest  that 
this  interaction  brings  in  a  need  to  organize,  integrate,  filter,  condense  and  annotate 
collaborative  data  and  other  relevant  information  that  these  team  participants  contribute.  Court 
( 1 997)  proposes  three  broad  categories  of  knowledge  that  designers  use  in  the  process  of 
developing  a  product  as  described  in  Table  1.  These  broad  categories  of  knowledge  along  with 
the  requirements  of  an  information  product  development  team  provide  a  better  understanding 
of  the  role  that  each  such  knowledge  type  plays  in  the  design  decision  processes  that  underlie 
the  development  of  an  information  product. 


Table  1:  Types  &  Characteristics  of  Knowledge  in  Information  Product  Development 
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Type  of  Knowledge 
Classification  and  Goal 

Characteristics  and  Comments 

Application  of  general 
knowledge 

Knowledge  that  people  gain  through  everyday  experiences  and  apply  without 
regard  to  any  specific  domain  they  might  be  working  in.  This  type  of  knowledge 
might  have  no  specific  or  direct  relation  with  the  task  domain  (Court,  1997)  that 
the  participant  on  the  IPD  team  is  engaged  in. 

Developing  a  synergy  of 
domain  specific  Knowledge 

This  type  of  knowledge  is  gained  through  study  and  experience  within  a  specific 
domain.  Domain  specific  knowledge  is  generally  improved  as  the  person(s) 
involved  in  task  domain  gain  more  experience  (Court,  1997).  Since  IPD  teams  are 
highly  cross  functional,  links  to  artifacts  and  processes  are  needed  to  share  domain 
specific  knowledge  (Fielding  et  al.,  1998).  Distributed  annotation  (Fielding  et  al., 

1 998)  can  also  provide  support  to  maintain  links  to  help  team  members  make 
contextual  interpretations  for  decisions  outside  their  domain  of  expertise  (Iansiti 
and  MacCormack,  1997;  Song  and  Montoya-Weiss,  1998). 

Applying  and  supporting 
procedural  Knowledge 

This  is  gained  from  experience  of  undertaking  a  task  within  the  domain.  Court 
(Court,  1997)  suggests  that  this  is  a  combination  of  the  above  two  types  of 
knowledge.  Procedural  knowledge  therefore  includes  domain  specific  knowledge 
and  domain  independent  knowledge  (Court,  1997;  Davidow  and  Malone,  1992; 
Leonard  and  Sensiper,  1998;  Nonaka  and  Takeuchi,  1995).  Since  expertise  might 
be  distributed  in  an  information  product  development  team,  the  ability  to  provide 
distributed  authoring  (Fielding  et  al.,  1998)  and  design  decision  coordination 
(Faraj,  1998;  Fielding  et  al.,  1998)  helps  bring  together  existing  expertise. 

3.3  Characteristics  of  Information  Products 

Examination  of  recent  literature  on  information  product  development  and  new  product 
development  processes  reveals  several  distinguishing  characteristics  of  information  products 
that  makes  them  different  from  tangible  physical  products.  We  list  these  characteristics,  later 
followed  by  an  analysis  of  the  problems  that  result  from  these  rather  distinct  characteristics. 
We  draw  up  on  a  case  study  of  a  specific  IPD  activity  (i.e.,  the  development  of  a  newspaper) 
in  our  discussion. 

A  newspaper  is  released  in  two  different  formats  -  Web  and  print,  typically  each  morning. 
This  process  involves  extensive  cross  functional  collaboration  on  the  design  on  this 
information  product.  Critical  layout  decisions  like  the  relative  placement  of  the  weather 
sidebar  or  daily  sports  scores  on  the  front  page  requires  inputs  from  a  diverse  variety  of 
stakeholders.  These  might  include  editorial,  marketing  and  sales,  advertising  and  management 
personnel.  Further,  the  product  is  developed  within  the  span  of  one  day  and  needs  to  integrate 
diverse  inputs  that  its  correspondents  and  news  feed  services  such  as  Reuters  provide.  An 
appropriate  balance  between  what  goes  on  the  Web-based  version  and  what  goes  into  the  print 
version,  is  needed  so  that  “sales”  of  one  version  are  not  cannibalized  by  the  other.  For 
example,  news  content  of  the  print  version  can  not  be  cut  down  extensively  since  it  might 
affect  daily  news  stand  sales.  On  the  other  hand  the  print  version  should  not  have  too  much 
content  that  the  Web  version  is  missing  as  that  might  de-mo tivate  future  ‘hits’  from  potential 
readers  and  Website  visitors.  Besides  content  and  layout  issues,  the  balance  of  similarities  and 
differences  in  the  design  of  the  print  and  the  Web  version  of  the  newspaper  are  also  critical 
issues  (Cottrell  and  Faulkner,  1998;  Techart,  1993).  We  will  return  to  this  example  throughout 
the  rest  of  this  paper  to  identify  problems  as  well  as  decision  support  solutions  provided  by  our 
research. 


Unusual  economics  of  production 

Information  products  have  unusual  economics  of  production  yet  are  subject  to  the  same  market 
and  competitive  forces  that  govern  the  fate  of  any  physical  product  (Shapiro  and  Varian,  1998; 
Shapiro  and  Varian,  1999).  In  a  local  newspaper,  the  first  copy  involves  significant  costs  and 


effort.  However,  every  subsequent  copy,  either  print  based  or  Web-based,  has  negligible 
marginal  cost.  In  case  of  the  Web-based  version  of  the  newspaper,  the  marginal  cost  of 
additional  copies  is  that  of  retrieving  content  through  a  Web  browser,  which  is  close  to  zero. 

Timeliness  of  delivery 

Timeliness  of  delivery  of  an  information  product  can  be  a  major  determinant  of  its  value  to  the 
consumer  (Ballou  et  ah,  1998),  who  may  be  either  internal  or  external  to  the  organization. 
Ballou  et  al.  (1998)  further  suggest  that  a  firm  can  possibly  create  competitive  advantage  by 
delivering  an  information  product  in  a  shorter  time-frame  than  initially  targeted.  In  our  case 
study,  the  success  of  a  newspaper  depends  on  its  ability  to  deliver  news  content  in  its  final 
fonn  at  a  minimum,  once  every  morning.  This  means  that  the  time  frame  from  product 
conception  to  production  spans  twenty-four  hours  for  most  content  components. 

Short  product  lifecycles 

Information  products  typically  enjoy  very  short  life  cycles  (Clark  and  Wheelwright,  1994; 
Fielding  et  ah,  1998;  Iansiti  and  MacCormack,  1997).  Furthermore,  the  underlying 
technologies  are  evolving  at  a  rapid  pace,  which  makes  the  process  lifecycle  shorter  as  well 
(Davenport,  1993).  Therefore,  the  time  available  for  recouping  expenses  associated  with  their 
development  is  compressed.  In  a  Web-based  news  delivery  service  run  by  a  local  newspaper, 
the  lifecycle  of  this  product  is  one  day,  after  which  its  economic  value,  approaches  zero. 

Cross  functional  collaboration 

In  order  to  respond  to  competitive  challenges  and  diverse  skill  sets  needed  to  develop  an 
information  product,  organizational  units  have  become  more  closely  coupled  than  in  the  past, 
often  working  in  parallel  to  complete  assignments  spanning  traditional  units  and  functional 
areas  (Iansiti  and  MacConnack,  1997;  Song  and  Montoya-Weiss,  1998).  Leonard-Barton 
(1998)  indicates  that  the  creation  of  today’s  complex  systems  of  products  requires 
amalgamation  of  knowledge  from  diverse  disciplinary  and  personal  skills-based  perspectives 
where  creative  cooperation  is  critical  for  innovation.  Physical  product  development  has  been 
classically  characterized  by  intricate  interdependencies  among  areas  such  as  manufacturing, 
marketing,  and  packaging.  Analogous  to  this,  the  development  of  information  products  might 
require  collaboration  among  people  from  different  skill  areas  and  functional  units.  Decisions, 
in  the  case  of  information  products,  relate  both  to  their  design/  structure  and  content. 

In  our  example,  a  critical  layout  decision  such  as  the  placement  of  the  weather  forecast 
requires  inputs  from  editorial,  sales,  marketing,  advertising  and  weather  specialists.  These 
participants  need  to  bring  in  their  past  knowledge  of  the  sales  impact  of  both  relative 
placement  of  this  content  and  the  content  itself  on  the  front-page.  Building  a  push  Web-based 
delivery  news  service  might  need  inputs  from  the  technical  staff,  software  coders,  hardware 
specialists  who  decide  on  the  hardware  specifications  needed  to  host  such  a  system,  network 
specialists  who  provide  Web  connectivity,  creative  design  artists  who  work  on  the  aesthetic 
design  aspects  and  marketing  staff  that  are  responsible  for  generating  advertiser  revenue. 

Ease  of  versioning 

Physical  product  manufacturers,  including  those  of  complex  engineering  products,  have  been 
able  to  version  products  and  sell  them  at  different  price  points.  For  example,  Intel  sells  two 
versions  of  its  Pentium  II  processor  -  a  regular  version  and  a  feature-  disabled  one  called  the 
Celeron™  at  a  lower  price  point.  Although  these  processors  are  internally  identical  and  cost 
almost  the  same  to  produce,  one  is  sold  at  a  lower  price  point  simply  by  disabling  the  internal 
cache  memory  section  on  the  chip.  While  functional  versioning  of  physical  products  can  be 
expensive,  relative  costs  of  versioning  information  products  to  create  artificial  differentiation 
is  lesser  expensive  (Shapiro  and  Varian,  1998).  Examples  of  such  versioning  of  information 
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products  include  trial  versions  of  software  programs  and  Web  sites  that  require  a  payment  in 
order  to  access  full  content.  Numerous  product  derivatives  can  be  creeated  from  a  central 
repository.  In  case  of  a  newspaper,  for  example,  a  common  content  base  can  be  used  to  spin 
off  a  print  version,  a  Web  based  version  customized  for  different  markets  or  locations  and  a 
CD-  ROM  archive  of  news  content. 

Inter-institutional  collaboration 

As  products  grow  increasingly  complex,  it  is  becoming  inevitable  for  multiple  organizations  to 
be  involved  in  the  development  of  a  single  product  (Iansiti  and  MacConnack,  1997).  This 
brings  together  participants  spanning  multiple  functional  disciplines  and  specializations  from 
across  multiple  collaborating  organizations  and  stakeholder  groups.  Such  traverse  institutional 
participants  might  come  from  different  cultures  and  backgrounds.  Therefore  there  is  a  need  to 
support  effective  collaboration  and  knowledge  sharing  among  these  participants  (Song  and 
Montoya-Weiss,  1998). 

For  example,  different  sister  newspapers  belonging  to  the  same  parent  company  might  be 
collaborating  on  their  news  stories.  Besides,  most  newspapers  depend  on  services  such  as 
Reuters  for  their  national  and  international  news  feed.  Weekend  comics  and  daily  comic  strips 
come  from  feature  syndicate  services  etc.  Consequently,  putting  together  such  an  information 
product  requires  collaboration  traversing  several  institutions. 

Temporary  information  product  development  teams 

In  large  development  projects,  membership  of  the  development  team  changes  both  across  time 
and  across  project  phases.  As  specialized  skills  are  needed,  members  from  within  the 
collaborating  organizational  units  are  drawn  into  the  project  on  an  ad-hoc  basis  and  they  return 
to  their  original  units  after  their  tasks  are  completed  (Iansiti  and  MacConnack,  1997;  Quinn  et 
ah,  1996).  Rapid  growth  in  the  consumer  market  and  the  specialized  skill-sets  necessary  are 
critical  factors  contributing  to  the  severe  shortage  of  qualified  personnel  and  high  turnover, 
especially  in  high  technology  areas. 

Uncertainty  in  evolving  markets 

Due  to  the  rapid  pace  of  change  and  evolution  in  the  information  product  markets  (as  observed 
by  (Meyer  and  Zack,  1996)),  organizations  involved  in  information  product  development  need 
to  cope  with  a  high  degree  of  uncertainty  over  fundamental  issues  that  normally  drive  the 
product  development  process  (Mullins  and  Sutherland,  1998).  Such  issues  might  include  the 
appropriateness  of  the  choice  of  a  certain  technology  standard  over  another,  the  nature  and 
extent  of  customer  needs,  uncertainty  about  the  level  of  resources  that  must  be  invested  and  the 
timing  of  commitments  (Mullins  and  Sutherland,  1998).  Recent  research  on  knowledge 
management  indicates  that  a  lot  can  be  learned  from  the  experiential  knowledge  within  the 
firm  to  help  alleviate  the  uncertainty  surrounding  such  issues  (Nonaka  et  ah,  1998;  Nonaka  and 
Takeuchi,  1995;  Powell,  1998;  Powell,  1967;  Quinn  et  ah,  1997). 

Perishability 

Perishability  refers  to  the  decrease  in  the  value  of  a  product  over  a  period  of  time.  Assessment 
of  the  perishability  of  an  information  product  has  to  take  into  account  the  specific  use  for  that 
occasion  (Koppius,  1 999).  This  supports  our  earlier  argument  that  the  value  of  an  information 
product  can  be  a  time -dependent  function.  For  example,  a  Web-based  news  service’s  daily 
content  diminishes  in  value  after  one  day. 

Specif  ability 

Specifiability  has  been  described  in  literature  as  the  ‘ complexity  of  description  ’  (Malone  et  ah, 
1987).  Koppius  (1999)  suggests  that  the  lack  of  sufficient  specifiability  of  an  information 
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product  is  a  major  problem  in  specifying  its  features.  High  specifiability  is  desirable  in  order  to 
reduce  customer  uncertainty  (Koppius,  1 999).  Having  descriptions  and  specification  from  past 
information  products  might  help  specify  new  products  through  partial  analogy. 

These  characteristics  of  information  products  pose  additional  challenges,  only  some  of  which 
are  common  to  physical  products.  These  challenges  are  further  compounded  when 
development  of  the  information  product  is  done  by  a  distributed  team  . 

3.3  Challenges  Faced  by  Information  Product  Development  Teams 

Distributed  collaboration,  especially  that  enabled  through  the  Web  as  a  communications 
medium,  faces  limitations  of  the  characteristics  of  the  medium  itself  (for  example,  as  described 
in  the  case  of  Web-based  development  by  Fielding  et  al.  (1998)).  We  focus  on  problems 
related  to  distributed  coordination  and  decision  making  in  the  process  of  design  decision 
making  through  the  Web.  Recent  literature  suggests  that  such  teams  face  the  problems 
identified  in  the  following  sections.  Each  problem  is  identified  with  a  problem  code  such  as 
{XX}  and  these  codes  are  further  used  to  map  system  goals  and  enabling  technology 
characteristics  (Table  2)  that  our  prototype  demonstrates. 

Lack  of  shared  understanding  {SU} 

Teams  developing  information  products  (IPs)  are  drawn  from  different  functional  areas  and 
streams  of  expertise  (Iansiti  and  MacCormack,  1997;  Song  and  Montoya-Weiss,  1998).  This 
creates  dependencies  among  different  functional  specializations  and  requires  inputs  from  these 
constituents  to  accomplish  joint  objectives  (Ramesh  and  Tiwana,  1999)  relating  to  IP  design. 
Such  team  members  come  with  their  differences  in  their  understanding  and  perspectives  of  the 
problems  faced  throughout  the  design  process  (Leonard-Barton  and  Sensiper,  1998).  Team 
members  drawn  from  different  disciplines  lack  an  understanding  of  the  critical  design  factors 
for  functional  areas  other  than  their  own.  Lack  of  a  common  vocabulary  and  limited  knowledge 
of  other  functional  areas  that  do  not  fall  under  the  participant’s  domain  creates  the  need  for  a 
shared  and  co-evolved  understanding  in  order  to  allow  consensus  on  the  design  decision 
making  processes  (Cross  and  White,  1996;  Webber,  1993). 

In  our  example,  there  are  multiple  stakeholders  involved  in  the  production  of  a  news  service. 
For  design  of  the  product,  advertising,  editorial  and  marketing  departments  need  to  provide 
inputs  to  maximize  a  common  goal:  Improved  sales  and  increased  customer  value.  However, 
these  goals  might  mean  different  things  to  participants  with  differing  functional  backgrounds. 
Hence,  there  needs  to  be  some  mechanism  to  allow  the  co-evolution  of  requisite  shared 
understanding. 

Loss  of  design  decision  context  due  to  changing  team  membership  {LC} 

Ad-hoc  teams  formed  for  new  product  development  are  often  dissolved  at  the  end  of  the 
project  (Ciborra,  1993;  Mankin  et  ah,  1996)  and  team  members  often  get  assigned  to  other 
projects  (Mankin  et  al.,  1996)  where  their  functional  expertise  is  required.  When  design 
decisions  are  made  by  teams  developing  an  information  product,  recording  the  decision 
without  its  context  is  insufficient  (Clark  and  Wheelwright,  1994).  While  static  teams  can 
partially  retain  the  context  of  their  past  decisions,  recent  research  suggests  that  most 
organizations  tend  to  deploy  dynamically  collated  teams  (Mankin  et  al.,  1996;  Tjosvold  and 
Tjosvold,  1991).  Nonaka  and  Takeuchi  (1995)  have  suggested  the  importance  and  value  of 
recognizing  and  capturing  tacit  information  -  information  that  can  not  be  transmitted  between 
team  members  such  as  know-how,  judgement  and  intuition  which  together  make  up  a  critical 
component  of  information  that  needs  to  flow  between  members  collaborating  within  a  team. 
The  success  or  failure  of  transfer  of  design  knowledge  between  team  members  over  time 
partially  depends  on  the  effective  transfer  of  the  tacit  component  of  knowledge  that 
collaborative  information  systems  do  not  capture  (Davenport  and  Prusak,  1998).  Dell  also 
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suggests  that  the  ability  to  capture  learning  in  organizational  units  and  teams  is  an  essential 
precedent  to  meaningful  transfer  and  sharing  of  knowledge  between  groups.  Therefore,  the  loss 
of  context  of  past  design  decisions  poses  a  threat  to  the  efficient  and  effective  design  of  newer 
versions  of  the  product  when  team  membership  is  not  stable. 

Reinvention  of  solutions  {RS} 

Reinvention  is  defined  as  “making  as  if  for  the  first  time  something  already  invented” 
(Webster,  1999).  Development  teams  reinvent  solutions  to  problems  that  might  have  already 
been  solved  (Clark  and  Wheelwright,  1994;  Mankin  et  ah,  1996)  due  to  their  lack  of  awareness 
of  historical  decisions  (Teece,  1998)  in  other  projects  both  within  and  outside  the  organization. 
Information  product  development  team  members  might  invest  resources  into  solving  problems 
that  might  have  already  been  solved  as  work  groups  often  repeatedly  discuss  the  same  issues 
that  have  been  resolved  earlier,  as  no  reliable  record  of  these  deliberations  may  exist  (Ramesh 
and  Dhar,  1992).  Court  (Court,  1997)  strengthens  this  argument  by  suggesting  that  product 
designers  often  tend  to  use  the  incomplete  information  they  already  possess,  which  results  in 
designs  being  generated  without  the  benefit  of  knowledge,  related  information  and  expertise 
that  might  already  exist  within  the  organization. 

Repetition  of  design  mistakes  { RM } 

Organizations  often  repeat  past  mistakes  in  design  decisions  (Davenport  and  Prusak,  1998; 
Dillon,  1997;  Dolan,  1993)  because  they  lack  episodic  knowledge  of  mistakes  that  might  have 
been  made  in  the  past  (Ramesh  and  Dhar,  1992;  Robillard,  1999).  Processes  that  would  support 
active  transfer  of  knowledge  from  successful  projects  to  new  ones  could  reduce  the  extent  of 
repetition  of  such  mistakes  (Ramesh  and  Dhar,  1992).  Teece  (1998)  suggests  that  innovations, 
such  as  (information)  product  development,  involve  a  considerable  degree  of  uncertainty. 
Retaining  and  actively  using  the  knowledge  of  episodic  failures  has  value  in  impelling 
allocation  of  resources  into  auspicious  directions  rather  than  repeating  past  mistakes  that  the 
existing  design  team  might  not  be  aware  of.  Having  a  mechanism  to  keep  track  of  past  design 
episodes  helps  maintain  traces  of  abandoned,  interrupted  and  failed  decisions  (Robillard, 
1999). 

For  example,  the  news  design  team  might  have  realized  that  not  placing  baseball  scores  on  the 
opening  page  negatively  affects  customer  satisfaction  and/or  sales.  If  the  design  team  is 
unaware  that  it  made  that  mistake,  say  three  years  back,  it  is  at  risk  to  make  the  same  design 
error  again. 

Skills  developed  due  to  collaboration  may  be  lost  for  subsequent  use  {LS} 

The  design  team  involved  in  the  development  of  a  successful  product  is  often  moved  to  the 
next  high  profile  project.  The  expertise  gained  during  development  of  the  product  is  not  readily 
available  to  design  teams  working  the  subsequent  versions  of  the  product  during  its  evolution 
(Ramesh  and  Tiwana,  1999).  The  primary  obstacle  to  successful  learning  from  alliances  is  the 
failure  to  execute  the  specific  organizational  processes  necessary  to  access,  assimilate,  and 
disseminate  alliance  knowledge  such  as  that  created  in  team-based  projects  (Inkpen,  1996). 
Recent  research  indicates  that  the  turnover  of  such  personnel  and  participants  poses  a  threat  to 
the  collective  knowledge  and  expertise  possessed  by  the  group  since  much  of  the  knowledge  is 
tacit  i.e.  situated  in  the  minds  of  the  collaborating  personnel  (Nonaka  et  al.,  1998;  Nonaka, 
1989;  Nonaka  and  Konno,  1998;  Nonaka  and  Takeuchi,  1995).  Similarly,  low  turnover  allows 
for  the  development  of  organizational  knowledge  and  expertise  as  well  as  fostering  a  high 
degree  of  socialization  (March,  1991;  March,  1999). 
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Inconsistent  versioning  of  design  information  {IV} 

There  is  no  way  to  guarantee  that  the  information  entered  is  always  up  to  date  unless  the 
upkeep  is  somehow  automated  (Teigland  et  ah,  1998). When  the  same  project  information, 
documentation,  design  or  decision  outcome  artifact  is  kept  at  multiple  locations,  ambiguities 
about  which  one  is  the  most  current  version  arise  (Ramesh  and  Tiwana,  1999).  The  need  for 
redundancy  however  must  be  met  simultaneously  with  the  need  for  maintaining  consistency 
across  different  versions  of  information  that  may  be  possessed  by  different  team  members 
(Sanchez  and  Heene,  1997).  Resources  and  design  decision  artifacts  need  to  be  shared  in  a 
manner  that  conflicting  versions  do  not  hamper  the  decision  making  processes  (Chang  and 
Jackson,  1996). 

Process  knowledge  might  he  lost  after  the  project  is  completed  {PK} 

In  a  project  oriented  team-based  organizational  structure,  skills  developed  during  the 
collaboration  process  might  be  lost  after  the  team  is  dissolved  and  redistributed  (Mankin  et  ah, 
1996).  When  a  team  is  disbanded,  the  process  knowledge  acquired  by  the  team  and  needed  for 
tasks  such  as  product  modification  or  maintenance  is  lost  for  future  use  (Ramesh  and  Dhar, 
1992).  Quinn  et  al.  (1996)  suggest  that  professional  know  how  is  developed  most  rapidly 
through  repeated  exposure  to  the  complexity  of  real  problems  i.e.  experience  gained  through 
collaborative  work.  Recent  research  suggests  that  this  process  knowledge  is  lost  because  the 
tacit  knowledge  that  the  team  develops  through  collaboration  (Davenport,  1993)  gets 
redistributed  (Fahey  and  Prusak,  1998).  Tacit  knowledge  is  an  integral  component  of 
knowledge  but  unlike  explicit  knowledge,  it  is  difficult  to  articulate  in  a  way  that  is  meaningful 
and  complete  (Nonaka  and  Konno,  1998).  Teece  (1998)  provides  further  support  to  this 
argument  by  suggesting  that  there  is  correlation  between  codification  of  knowledge  and  the 
cost  of  its  transfer  from  one  group  to  another.  The  larger  the  extent  to  which  decision  and 
design  knowledge  has  been  codified,  the  lower  are  its  transfer  costs  between  members  in  a 
given  team  and  across  teams  (Teigland  et  ah,  1998). 

Unstated  assumptions  { UA } 

Several  design  decisions  made  in  the  process  of  developing  a  new  product  might  be  based  on 
some  technical  (Ramesh  and  Dhar,  1992)  or  procedural  (Bohn,  1994)  assumptions  made  by 
design  team  participants.  Since  team  members  might  be  pooled  in  from  different  functional 
specializations,  such  assumptions  might  not  be  apparent  to  other  team  members.  If  such  an 
assumption  is  made  at  an  early  stage  in  the  design  process,  it  may  affect  later  stages  of  product 
design.  As  the  number  of  decisions  grow  and  their  corresponding  relationships  become 
complex,  it  becomes  difficult  to  trace  the  effects  of  changes  in  such  assumptions  on  the  rest  of 
the  design.  Court  ( 1 997)  suggests  that  the  requirements  that  a  product  needs  to  satisfy  might 
change  over  the  period  of  its  development.  Iansiti  (1997)  further  strengthens  this  argument  by 
giving  the  example  of  Netscape  Corporation’s  development  effort  for  its  early  browser  (an 
information  product),  where  the  design  requirements  and  underlying  assumptions  evolved  and 
changed  even  after  the  information  product  development  team  began  building  the  designed 
product.  Lacking  the  ability  to  trace  and  take  into  account  the  effect  of  a  changed  assumption 
on  the  rest  of  the  design  decisions  that  might  have  already  been  made  might  negatively  affect 
the  outcomes  of  the  development  effort  and  in  turn  success  of  the  product. 

In  our  example  of  a  newspaper’s  Web  news  delivery  mechanism,  participants  on  the  design 
team  who  are  involved  in  decision  making  process  come  with  different  assumptions  which  are 
brought  in  from  their  differing  areas  of  specialization.  What  might  be  the  most  important 
design  factor  for  an  advertising  manager  (advertisement  revenue)  might  be  different  from  that 
for  an  editor  (news  content  density)  (Cottrell  and  Faulkner,  1998)  and  so  forth. 
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3.4  Characteristics  of  a  System  to  Support  Information  Product  Development 
Design  Decision-making 

The  problems  identified  above  pose  challenges  to  an  information  product  development  team 
collaborating  on  the  development  of  an  information  product  within  a  distributed  space. 
Tracking  the  history  of  design  decisions  (Robillard,  1999)  can  help  information  product 
designers  in  accounting  for  changes  in  design  assumptions  and  evolving  market  needs  (Shapiro 
and  Varian,  1998).  Maintenance  of  traces  for  abandoned  and  interrupted  design  decisions  can 
help  avoid  rework  (Robillard,  1999).  Maintenance  of  metadata  on  decisions  made  in  the  past 
can  help  designers  apply  and  reuse  lessons  learned  from  past  decisions  (Fielding  et  ah,  1998). 
Our  work  is  based  on  the  premise  that  if  knowledge  about  the  history  of  design  is  captured  and 
maintained,  it  can  alleviate  many  of  these  problems  associated  with  IPD.  The  challenge  in  this 
research  is  to  represent  this  historical  record  in  a  way  that  it  supports  decision-makers  involved 
in  the  development  of  an  information  product. 

As  our  research  is  geared  towards  developing  decision  support  systems  for  this  purpose,  it  is 
focused  on  capturing  and  representing  knowledge  about  the  decisions  made  during  IPD 
process.  Recent  research  recognizes  that  maintaining  knowledge  about  just  the  decisions 
themselves  is  not  sufficient  to  foster  shared  understanding  of  the  required  decisions  among  the 
decision-makers  involved  in  IPD.  As  much  context  of  such  decisions  as  possible,  must  also  be 
maintained  (Robillard,  1999). 

Mapping  IPD  Problems  to  System  Goals  and  Characteristics 

Recent  research  on  information  products  proposes  several  goals  for  supporting  distributed 
coordination  and  design  decision  making  of  information  products  (Fielding  et  ah,  1998).  In 
Table  2,  we  map  these  goals  to  IPD  problems  identified  in  the  previous  section  and  further 
translate  these  goals  to  enabling  technology  solutions.  The  first  column  in  Table  2  describes 
the  goals  as  described  by  Fielding  et  al.  (1998).  The  set  of  information  product  development 
problems  identified  in  the  preceding  section  that  each  goal  addresses  is  represented  by  its  code 
in  the  second  column.  Enabling  technologies  to  support  IPD  processes  are  identified  in 
Column  3. 


Table  2:  Enabling  technology  for  design  decision  support  in  distributed  collaborative  IPD. 


Goal  (Fielding  et  al.,  1998) 

IPD  problems 
addressed 

Enabling  technology  for  design  decision 
support 

Distributed  coordination  and  design  decision 
making 

{SU},  {RS}, 
{RM},  {IV} 

All  of  the  below 

Linking  artifacts  to  processes 

{LC},  {RM} 

Links  between  process  knowledge  and 
artifacts 

Flexible  interaction  model  and  hypermedia 
services 

{PK},  {UA} 

Formal  and  informal  media;  hyper-media  links 

Distributed  annotation 

{SU},  {RM} 

Distributed  annotation  of  artifacts  with 
concept  maps 

Distributed  authoring 

{LS},  {IV} 

Distributed  authoring  of  process  knowledge 
and  concept  maps 

Visibility  of  artifacts  over  time 

{LC},  {RS}, 
{PK} 

Recording  of  design  development  history  / 
process  knowledge 

Towards  a  Mechanism  for  Supporting  IPD  Knowledge 

We  have  developed  a  design  decision  support  system  to  provide  a  variety  of  enabling 
technologies  identified  in  Table  2.  The  facilities  provided  by  this  system  include: 
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•  A  WWW  based  group  support  environment  in  which  the  various  participants  can  conduct 
deliberations  leading  to  IPD  decisions 

•  Facilities  for  capturing  the  context  in  which  these  decisions  are  made.  Using  a  distributed 
multimedia  annotation  system,  the  decisions  and  the  rationale  for  these  decisions  can  be 
linked  to  the  artifacts,  supporting  documents  and  other  related  information  on  the  WWW. 

•  A  facility  to  manage  the  complex  network  of  dependencies  among  the  various 
components  of  knowledge  often  thinly  spread  across  the  various  participants  in 
collaborative  teams. 

•  A  facility  for  intelligent  retrieval  of  components  of  design  decision  knowledge  based  on 
ad-hoc  requirements  of  the  various  participants. 

•  A  mechanism  to  maintain  the  consistency  of  the  captured  knowledge  so  that  the 
knowledge  is  current  and  accurate 

Linking  Artifacts  to  Processes 

Kline  et  al.  (1998)  stress  the  importance  of  integrating  tools  for  supporting  collaborative  work 
within  the  context  of  the  work  environment.  We  provide  a  variety  of  support  mechanisms  to 
address  this  issue:  We  recognize  the  importance  of  relating  process  knowledge  to  the  artifacts 
that  are  outcome  of  the  processes.  We  provide  a  model  for  capturing  deliberations  in  which 
components  of  process  knowledge  (such  as  requirements,  assumptions,  decisions,  assumptions 
etc.)  can  be  captured  For  example,  the  conversations  may  be  conducted  using  REMAP,  a 
model  based  on  the  IBIS  argumentation  model  (Ramesh  and  Dhar,  1992).  Using  our  tool,  the 
users  can  not  only  capture  details  of  the  deliberations,  but  also  maintain  links  to  the  artifacts 
that  are  the  “inputs”  and  “outputs”  of  these  deliberations.  For  example,  the  components  of  a 
deliberation  on  the  production  different  versions  of  a  CD-ROM  IPD  can  have  embedded  in 
them,  links  to  the  actual  code  (represented  in  the  HTML  format).  Similarly,  a  link  embedded  in 
the  artifacts  can  be  used  to  retrieve  a  discussion  related  to  its  creation  and  maintenance  as 
shown  in  Figure  1. 


Figure  1:  Linking  artifacts  to  processes 
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Flexible  Interaction  Model  and  Hypermedia  Services 

Design  history  can  be  represented  in  varying  degrees  of  fonnality.  Formal  representations  can 
help  automated  reasoning,  but  are  difficult  to  develop  in  most  complex,  dynamic  design 
situations..  Whereas  informal  descriptions  help  create  thick  descriptions,  indexing,  retrieval 
and  formal  reasoning  with  such  information  can  be  difficult.  We  provide  the  flexibility  to 
represent  process  knowledge  in  a  variety  of  fonns  ranging  from  formal  specifications  to 
hypermedia  objects.  For  example,  the  belief  in  an  assumption  can  be  represented  formally, 
whereas,  the  video  /audio  clips  of  discussions  involving  demonstrations  of  various  versions  of 
the  IP  can  be  represented  using  hypermedia. 

Depending  on  the  complexity  and  importance  of  a  decision,  the  rationale  behind  it  may  be 
captured  at  different  degrees  of  detail.  Our  system  provides  the  flexibility  to  represent  decision 
rationale  at  different  levels  of  granularity  or  detail.  In  the  simple  view,  the  users  can  annotate 
their  decisions  with  notes  and  assumptions.  In  the  detailed  view,  however,  they  can  create  a 
complex  network  of  requirements,  issues,  alternatives,  arguments  and  assumptions  that  were 
critical  in  arriving  at  a  decision. 

Distributed  Annotation 

Boland  and  Tenkasi  (1995)  argue  that  it  is  essential  to  support  explicit  representations  for 
exchange  of  views  and  undertakings  among  distributed  team  members.  We  support  explicit 
representation  of  ideas  and  viewpoints  using  concept  maps.  These  maps  can  be  used  by  the 
participants  to  create  detailed  representation  of  the  variables  and  assumptions  used  by  them  in 
defining  problem  and  solution  spaces.  In  complex  situations  the  team  members  may  use 
different  variables  to  describe  the  problem  and  solution  spaces.  Further,  different  members  of  a 
team  may  use  the  same  term  with  different  meanings.  The  concept  maps  representing  such 
information  can  be  thought  of  as  annotations  (Boland  and  Tenkasi,  1995)  explaining  the 
viewpoints  of  individual  participants  that  contributed  to  the  development  of  the  information 
product.  Consider  the  scenario  in  which  an  editorial  staff  member  proposes  a  layout  of  the 
WWW  version  of  a  newspaper  that  prominently  places  an  editorial  segment.  This  team 
member  may  explain  the  philosophy  behind  his  design  by  clearly  identifying  the  variables  s/he 
considers  important  in  prioritizing  various  segments  to  be  accommodated  in  the  newspaper. 
This  ability  to  link  knowledge  about  the  problems  and  solutions  to  the  artifacts  can  be  used  by 
the  various  team  members  to  created  distributed  annotations  on  the  information  products 
developed  collaboratively. 

Distributed  Authorship 

Our  tool  is  based  on  a  client  server  architecture  in  which  clients  may  be  distributed  over  local 
or  wide  area  networks.  The  clients  connect  to  a  centralized  knowledge  base  to  retrieve,  define 
and  modify  components  of  process  knowledge  and  concept  maps.  This  architecture  supports 
distributed  authoring  by  team  members. 

Visibility  of  Artifacts  over  Time 

A  major  concern  with  the  development  of  information  products  is  loss  of  knowledge  about  the 
history  of  the  evolution  of  information  products  over  time,  which  leads  to  many  of  the 
problems  discussed  in  section  3.  For  example,  the  current  layout  of  an  online  newspaper  can 
be  best  understood  only  if  the  previous  versions  of  the  layout  as  well  as  the  reasons  behind  the 
changes  made  to  the  prior  versions  that  led  to  the  current  version  are  readily  available.  Our 
system  provides  the  facilities  to  capture  this  information  about  the  history  of  evolution.  By 
capturing  the  various  issues  considered,  the  alternative  solutions  proposed,  the  arguments 
supporting  and  opposing  each  of  these  alternatives  and  the  assumptions  behind  each  of  these, 
the  designers  can  explicitly  articulate  the  rationale  behind  the  evolution  of  their  artifacts  over 
time. 
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In  the  following  section  we  describe  the  functionalities  of  the  DSS. 

4.  Design  Decision  Support  System 

Our  DSS  provides  facilities  for  defining,  browsing  and  modifying  knowledge  about  history  of 
development  of  information  products.  We  illustrate  the  capabilities  of  the  system  using 
scenarios  on  the  development  of  various  versions  of  an  online  newspaper. 

4.1  Linking  Process  to  Artifacts 

Consider  the  situation  in  which  a  team  of  developers  is  involved  in  designing  the  layout  of  the 
newspaper.  Several  participants  contribute  to  this  important  decision.  They  range  from  the 
editors  in  charge  of  the  various  sections  such  as  sports,  business,  technology  etc.  as  well  as 
functional  areas  such  as  marketing  that  is  responsible  for  the  sale  of  the  paper  and  advertising 
that  is  responsible  for  generating  advertisement  revenues.  The  discussions  among  these  team 
members  may  be  conducted  using  our  tool.  Figure  2  shows  the  results  of  such  a  discussion. 
The  discussion  centers  on  the  requirements  for  designing  the  front  page  of  the  layout.  Varieties 
of  concerns  or  issues  that  are  raised  by  the  team  members  include  the  following: 

•  Does  information  about  weather  belong  in  the  front  page? 

•  Does  information  on  sports  scores  belong  in  the  front  page? 

Each  of  these  issues  in  turn  may  lead  to  more  specific  questions  such  as  where  in  the  front 
page  will  the  weather  information  be?  How  much  space  should  be  allocated  in  the  front  page 
for  the  weather  information?  etc.  The  team  members  involved  in  the  weather  section  may 
propose  alternative  solutions.  For  example,  a  team  member  suggests  that  this  segment  belongs 
in  the  banner  based  on  the  argument  that  it  will  provide  high  visibility.  This  argument  is  based 
on  the  assumption  that  the  target  audience  desires  such  a  high  visibility  placement  of  weather. 
Similarly,  other  team  members  propose  different  alternatives.  They  also  support  and/or  oppose 
the  various  alternatives.  Figure  2  also  shows  a  fragment  of  a  discussion  on  the  placement  of 
sports  scores.  Each  of  the  proposed  alternatives  has  a  direct  effect  on  the  final  layout  to  be 
chosen.  Based  on  the  evaluation  of  the  various  alternatives  (to  be  discussed  in  more  detail 
below)  the  team  makes  a  decision  to  choose  one  of  the  alternatives.  Our  tool  provides  the 
ability  to  hyperlink  this  decision  to  the  corresponding  layout  design.  Thus,  the  rich  history 
behind  the  choice  of  the  layout  is  captured  in  detail  and  linked  to  the  artifact  itself. 

4.2  Flexible  Representation  and  Hypermedia 

In  the  above  scenario,  the  representation  of  history  behind  design  decisions  was  guided  using 
the  primitives  of  an  extended  Issue  Based  Information  System  model  (Conklin  and  Begeman, 
1988;  Ramesh  and  Dhar,  1992).  However,  the  tool  provides  the  flexibility  to  customize  the 
representation  in  a  number  of  ways.  First,  a  different  conversation  protocol  may  be  used 
simply  by  changing  the  schema  that  represents  the  nodes  and  links  in  the  model  of 
collaboration.  Second,  we  recognize  that  a  team  may  wish  to  represent  the  history  behind 
decisions  at  varying  levels  of  detail  or  granularity.  The  discussion  in  Figure  2  represents  a  very 
detailed  model  (see  Appendix  2  for  a  legend).  Instead,  the  users  may  switch  to  a  simple  model 
in  which  only  the  decision  and  the  assumptions  may  be  recorded.  By  providing  this  flexibility, 
the  tool  enables  the  capture  of  history  at  the  desired  level  of  detail.  Two-way  linking  between 
the  artifacts  and  the  design  history  is  provided  by  the  ability  to  embed  the  reference  to  any 
specific  discussion  within  any  hypermedia  document.  For  example,  various  segments  of  a 
layout  represented  in  the  hypermedia  format  may  have  references  to  the  discussions 
corresponding  to  that  choice.  A  user  can  therefore  seamlessly  move  from  the  discussion  to  the 
artifact  and  vice  versa. 
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Figure  2:  A  design  decision  discussion  with  two  way  links  between  artifacts. 


The  need  to  represent  the  context  in  which  decision  are  made  is  supported  in  our  model  by  the 
ability  to  hyperlink  any  node  in  the  model  to  hypermedia  documents.  For  example,  the 
alternative  to  use  a  weather  strip  at  the  bottom  of  the  page  may  be  supported  by  the  argument 
that  it  is  the  format  employed  by  a  competing  publication.  A  hyperlink  to  that  publication  may 
be  created  to  completely  capture  the  context  in  which  this  argument  was  made  (see  Add  Node 
insert  in  Figure  2). 

4.3  Distributed  Annotation 

The  tool  supports  distributed  annotation  with  concept  maps.  Again,  the  concepts  to  be  used  to 
help  communicate  different  viewpoints  may  be  specified  by  the  team  members.  For  example,  a 
team  may  use  decision  variables  as  the  concept  of  interest.  Each  member  of  the  team  involved 
in  layout  design  may  describe  the  various  variables  that  they  consider  as  important  in  arriving 
at  a  layout.  Marketing  and  Advertising  may  be  interested  in  attractive  design  and  potential  for 
increased  advertising  revenues  respectively  as  their  top  priorities.  The  other  team  members 
may  seek  clarifications  on  these  concepts  to  fully  understand  the  respective  viewpoints. 
Marketing  may  elaborate  on  its  choice  to  mean  the  use  of  color  and  rich  media  as  enhancing 
the  attractiveness  of  the  design.  Similarly,  other  team  members  may  use  this  facility  to  specify 
their  choices  and  elaborate  on  them.  This  ability  to  exchange  viewpoints  enhances  the  chances 
for  shared  understanding  among  team  members,  which  is  essential  for  successful  collaboration. 

4.4  Distributed  Authoring 

Our  prototype  DSS  supports  distributed  development  of  information  products  with  a  client 
server  architecture.  The  clients  can  be  invoked  from  a  Web  browser.  The  team  members  using 
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the  client  interface  can  connect  to  a  central  knowledge  server  that  maintains  process 
knowledge  components.  This  facilitates  distributed  authoring  of  design  history  and  concept 
maps  by  the  team  members. 


Figure  3:  Distributed  authoring,  links  to  external  knowledge  sources(in  this  case,  a 
competitor’s  site)  and  relevant  real  time  deliberations  can  be  captured  and  linked  to 

design  decisions  as  they  are  made 

Figure  3  illustrates  the  use  of  the  DSS  in  conjunction  with  Netmeeting,  a  collaboration  support 
environment.  The  IPD  team  is  engaged  in  the  discussion  on  the  position  of  the  weather 
segment  in  the  front  page  using  the  chat  utility.  A  team  member  who  suggests  positioning 
weather  in  the  banner,  shares  a  Web  browser  that  displays  the  competitor’s  design.  Our  system 
complements  Netmeeting’ s  ability  to  support  conversations  and  share  applications  in  a  number 
of  ways.  The  essential  aspects  of  unstructured  conversations  conducted  within  Netmeeting, 
can  be  captured  within  our  tool  in  a  semi-structured  format.  Segments  of  the  conversations  can 
be  directly  imported  into  the  nodes  in  our  network  of  design  history.  Further,  the  artifacts 
themselves  can  be  two-way  linked  to  the  contents  of  the  conversations.  As  mentioned  earlier, 
the  competitor’s  Web  page  can  be  linked  to  the  argument  and  the  decision  to  the  layout  that 
displays  weather  in  the  intended  position. 

4.5  Decision  Support  with  Visibility  of  Artifacts  over  Time 

Our  tool  provides  a  variety  of  decision  support  aids  to  not  only  capture  knowledge  about  the 
history  of  development,  but  also  to  maintain  the  consistency  of  such  knowledge  and  perform 
automated  decision  support  with  that  knowledge,  especially  when  the  context  in  which  the 
decisions  are  made  change.  Recall  that  the  validity  of  the  alternatives  proposed  also  depends 
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on  the  validity  of  the  assumptions  behind  these  alternatives.  Simon  (1991)  suggests  that  all 
stakeholders  involved  in  the  delivery  of  a  product  must  be  involved  from  its  inception.  He 
gives  an  example  of  manufacturing  industries  where  the  failure  to  consider  manufacturability 
at  an  early  stage  usually  causes  extensive  redesign  with  a  product,  thereby  causing  major 
delays  in  production  and  subsequent  delivery  (Simon,  1991).  For  example,  the  suggestion  to 
use  the  banner  for  weather  is  based  on  the  assumption  that  such  a  high  visibility  placement  is 
desired  by  the  customer  market  segment. 

The  marketing  department  may  be  asked  to  evaluate  this  assumption.  If  they  invalidate  this 
assumption,  then  the  system  propagates  the  effects  of  this  assertion  to  invalidate  the  decision. 
Similarly,  the  evaluation  of  the  assumption  about  the  current  interest  in  the  sports  segment  may 
lead  to  the  validation  of  the  alternative  to  use  the  banner  for  sports  scores.  This  ability  to 
dynamically  synthesize  the  layout  based  on  process  knowledge  can  be  very  valuable  in  a 
variety  of  ways.  For  example,  two  editions  of  the  same  paper  produced  in  different  cities  may 
be  composed  with  different  layouts  based  on  their  specific  conditions  (whereas  sports  may  be 
at  the  top  priority  for  a  city  in  Southern  California  hosting  a  sporting  event,  weather  may  be 
most  appropriate  for  a  city  in  the  north  east  facing  a  major  stonn).  First,  the  system  helps 
synthesize  these  designs  based  on  a  common  and  consistent  set  of  design  principles  discussed 
by  the  team  members.  Second,  when  the  context  in  which  the  decisions  are  made  changes 
(which  is  common  in  the  development  of  information  products  like  an  online  newspaper  where 
new  stories  of  high  importance  may  develop  at  any  time),  the  system  helps  rapidly  identify 
components  of  the  design  that  are  valid.  Finally,  the  history  of  the  development  of  the 
information  product  is  captured  in  its  complete  fonn  so  that  the  teams  will  have  access  to  this 
information  when  designing  other  versions  of  the  product.  Our  system  supports  ad-hoc  queries 
to  retrieve  components  of  this  history  to  support  decision  making.  For  example,  a  design  team 
may  want  to  review  what  the  layout  looked  like  when  similar  conditions  existed  in  the  past 
and  more  importantly,  why  so?  The  ability  to  access  and  reuse  such  information  will  be 
extremely  valuable. 

5  Related  Work 

Many  tools  for  capturing  design  rationale  proposed  in  the  literature  use  argumentation  models 
such  as  issue  based  information  systems  (Conklin  and  Begeman,  1988).  Tools  such  as  (Conklin 
and  Begeman,  1988)  and  IBE  (Lease  et  al.,  1990)  provide  only  passive  support  for  the  capture 
of  rationale.  In  contrast,  we  advocate  active  support  for  both  capture  and  use  of  history.  Our 
work  is  similar  in  spirit  to  that  of  the  SYBYL  project  (Lee,  1990)  in  providing  automated 
reasoning  tools.  Our  work  extends  this  support  further  by  providing  mechanism  for  distributed 
coordination  with  annotation  and  authoring,  as  well  as  providing  links  between  artifacts  and 
design  history. The  need  for  hypermedia  annotation  of  artifacts  has  been  suggested  by  prior 
research  (Bhargava  et  al.,  1994).  Our  approach  extends  such  proposals  by  documenting 
detailed  design  history  in  a  semi-structured  way  so  that  automated  support  for  the  use  of  this 
information  can  be  provided.  This  research  differs  from  earlier  work  on  the  capture  of  semi- 
structured  history  information  exemplified  by  tools  that  support  IBIS  and  its  extensions 
(Conklin  and  Begeman,  1988;  Ramesh  and  Dhar,  1992)  in  its  focus  on  providing  a  tight 
integration  between  the  process  knowledge  and  the  artifacts  themselves.  In  the  domain  of 
information  product  development,  the  tight  integration  between  the  process  knowledge 
components  and  artifacts  themselves  can  be  maintained.  The  synthesis  of  a  design  solution  can 
readily  be  supported  when  the  context  for  the  design  decisions  change.  Thus,  whereas  the 
focus  of  decision  support  in  the  current  research  is  the  synthesis  of  information  products,  prior 
research  has  concentrated  on  providing  access  to  history  to  help  design  teams  working  in  the 
later  phases  of  a  project  or  a  future  project.  The  scope  for  opportunistic  planning  and  synthesis 
are  high  in  IPD  (Robillard,  1999)  and  our  decision  support  tools  are  geared  towards  supporting 
these  activities.  Recent  studies  on  the  use  of  structured  argumentation  techniques  to  capture 
organizational  memories  suggests  that  complex  models  are  appropriate  for  some  “wicked” 
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problems  whereas  simpler  schemes  are  more  appropriate  for  other  contexts  (Shum,  1998).  This 
finding  supports  our  approach  of  supporting  the  capture  and  use  of  history  at  multiple  levels  of 
abstraction  or  detail.  Though  the  WWW  has  emerged  as  an  important  medium  for  the 
production  and  delivery  of  information  products,  the  current  WWW  infrastructure  has  several 
missing  elements  for  the  development  of  annotation  systems  (Vasudevan  and  Palmer,  1999). 
We  have  proposed  an  annotation  system  that  complements  the  capabilities  currently  available 
on  the  WWW. 

6  Discussion 

The  capture  of  knowledge  about  the  history  of  development  can  be  very  expensive.  However, 
studies  in  the  domain  of  software  engineering  (such  as  (Yakemovic  and  Conklin,  1990)) 
document  the  feasibility  and  usefulness  of  such  efforts  even  in  large-scale  projects.  Even  in 
domains  where  the  tight  integration  of  design  process  knowledge  and  the  artifacts  can  not  be 
easily  maintained,  the  benefits  of  maintaining  comprehensive  design  history  have  been 
observed  (Ramesh  and  Sengupta,  1995).  Due  to  the  tight  integration  between  process 
knowledge  and  the  information  products  themselves,  the  benefits  of  design  history  information 
can  be  significantly  higher.  Bellanger  et  al.  (1997)  note  that  such  a  process  oriented  approach 
to  publishing  is  generalizable  to  a  certain  level  of  granularity  for  all  companies  developing 
such  products.  While  our  example  discussed  a  scenario  involving  layout  and  content  issues  in 
the  development  of  information  products,  it  can  also  be  applied  to  other  IPD  processes  such  as 
color  configuration  in  the  product  planning  stages,  “repurposing”  components  of  an 
information  product  and  distribution  (Bellander  et  al.,  1997).  However,  detailed  empirical 
studies  crucial  to  establish  the  effectiveness  of  the  approach  proposed  here  are  the  subject  of 
ongoing  research. 

The  overhead  involved  in  the  capture  of  history  can  be  significantly  reduced  if  the  information 
can  be  captured  in  a  non-intrusive  manner.  We  are  currently  investigating  the  use  of  concept 
classification  techniques  to  identify  components  of  this  knowledge  from  chat  and  e-mail 
exchanges. 
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Appendix  1:  Additional  Examples  (Case  studies  reproduced  from  Fuller  and 
Russel,  1994). 

1.  USE  OF  REMAP  IN  REQUIREMENTS  ENGINEERING 

During  the  requirement  phase  of  a  project,  detailed  knowledge  of  the  background  and 
history  of  the  system  is  required  in  order  to  make  sound  decisions  concerning  the 
system's  design  requirements.  For  example,  when  a  system  designer  is  building  a  new 
user  interface,  s/he  should  have  a  deep  understanding  of  how  the  interface  would  be 
used,  and  what  the  potential  users  will  need  to  effectively  perform  their  jobs.  This 
portion  of  the  example  illustrates  how  REMAP  could  be  used  during  the  requirements 
phase  to  effectively  capture  this  essential  background  information. 


1 .  Background  Information 

When  the  power  company  first  began  providing  power,  its  clients  were  located  in  the 
downtown  Jacksonville  area.  As  the  city  grew  and  expanded,  outlying  cities  such  as 
Jacksonville  Beach,  Neptune  Beach,  and  Orange  Park  were  incorporated  into  the 
company's  power  grid,  making  Jacksonville  the  largest  geographical  city  in  the  United 
States.  Today,  the  city  has  expanded  to  include  all  of  Duval  County,  an  area  of  nearly 
840  square  miles.  The  city  has  experienced  a  population  growth  rate  of  nearly  28 
percent  in  the  past  ten  years,  and  power  demands  have  increased  at  a  similar  rate. 

To  improve  the  service  to  this  expanding  city  while  dealing  with  company-wide 
downsizing,  the  power  company  has  determined  that  an  automated  service  order 
processing  system  is  the  most  economical  solution.  This  new  system  must  provide  a 
more  efficient  means  of  handling  calls  from  the  customer  for  maintenance  and 
emergency  service,  and  allow  the  company  to  dispatch  troubleshooters  in  the  most 
effective  manner. 

Presently,  the  power  company  operates  four  regional  centers.  Each  center  consists  of 
3-5  phone  Service  Operators  who  answer  calls  from  within  their  service  area.  These 
operators  provide  the  customer  with  a  variety  of  services,  arrange  electrical  service 
start  or  stop  dates,  answer  any  billing  question  the  customer  might  have,  as  well  as 
take  any  trouble  call  information  from  the  customer  and  forward  the  information  to 
the  service  dispatcher.  The  Service  Dispatcher  prioritizes  daily  work  schedules, 
assigns  jobs  to  field  units,  and  monitors  the  progress  of  all  field  workers.  The  field 
workers  have  to  coordinate  there  work  with  the  distribution  operator.  The  Distribution 
Operator  coordinates  all  field  maintenance  from  a  central  location. 

The  new  system  must  allow  the  company  to  expediently  dispatch  their  limited  number 
of  linesmen  more  effectively.  When  a  service  call  comes  into  the  center,  a 
Multipurpose  Customer  Service  Order  or  service  tag  is  generated.  This  tag  contains  all 
relevant  information  about  the  customer  service  request.  When  there  is  a  large-scale 
power  outage,  thousands  of  these  tags  can  be  generated.  In  order  to  dispatch  the 
limited  number  of  troubleshooters  to  the  most  likely  source  of  the  outage,  the  tags 
must  first  be  manually  sorted  by  geographic  area.  Once  these  tags  are  sorted,  they 
must  then  be  cross-referenced  with  a  power  Grid  map  according  to  substation  and 
feeder  lines  .  From  this  map,  a  more  precise  localization  of  where  the  trouble  is  can  be 
determined.  Since  this  is  all  performed  manually,  it  can  typically  take  several  hours  to 
localize  and  dispatch  troubleshooters  to  the  proper  area. 
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With  the  Current  Switching  Method,  switches  must  be  manually  opened  and  tested  to 
determine  if  they  are  indeed  the  trouble  spot,  or  the  problem  exists  somewhere  else 
along  the  line.  Once  the  exact  location  of  the  trouble  has  been  determined,  the 
troubleshooters  can  begin  working  on  the  solution  to  the  problem.  With  the  current 
system,  it  is  not  uncommon  for  15-24  hours  to  pass  before  power  can  be  restored. 
With  the  installation  of  the  Intelligent  Switches  And  Fuses,  the  power  company's  goal 
is  to  completely  automate  the  service  system.  Each  client's  address  will  be  linked  to  a 
particular  fuse  or  switch,  allowing  the  computer  to  expediently  localize  the  trouble 
spot.  The  intelligent  switches  and  fuses  will  allow  for  some  of  the  repair  work  to  be 
completed  remotely.  The  distribution  operator  needs  simply  to  switch  the  intelligent 
switch  on  or  off  over  the  phone.  This  will  allow  for  more  expedient  troubleshooting 
before  having  to  dispatch  workers  to  the  field.  This  new  system  must  provide  a  more 
efficient  means  of  handling  the  processing  of  customer  maintenance  request  status. 
Once  the  troubleshooters  are  on  site,  they  must  assess  the  situation  and  notify  the 
regional  center  of  the  estimated  time  that  will  be  required  to  fix  the  problem.  This 
information  is  currently  first  passed  to  the  dispatcher  from  the  linesmen.  From  there  it 
is  forwarded  to  the  service  center  operators,  time  permitting,  where  it  is  then  posted 
on  a  chalkboard  so  the  operators  can  inform  calling  customers  of  the  estimated  time 
until  their  service  is  restored.  The  linesmen  then  coordinate  with  the  distribution 
operator  to  ensure  that  they  can  safely  perform  the  maintenance  without  endangering 
other  workers  or  themselves. 

Finally,  after  the  work  has  been  completed,  every  person  who  called  in  must  be 
contacted  to  determine  if  their  power  has  been  restored.  If  their  power  is  not  back  on, 
the  entire  process  must  be  repeated. 

2.  Service  Operators 

Presently,  the  power  company  operates  four  regional  centers.  The  four  regional 
service  centers  are  divided  geographically. 

Region  One:  North  of  I- 10,  West  of  1-95: 
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Region  Two,  Region  Three,  Region  Four.  Each  center  consists  of  3-5  phone  operators 
who  answer  calls  from  within  their  service  area.  These  operators  provide  the  customer 
with  a  variety  of  services,  arrange  electrical  service  start  or  stop  dates,  answer  any 
billing  question  the  customer  might  have,  as  well  as  take  any  trouble  call  information 
from  the  customer  and  forward  the  information  to  the  service  dispatcher. 


3.  Service  Dispatcher 

The  service  dispatcher  plays  a  vital  role  within  the  maintenance  system  of  the  power 
company.  Due  to  the  extremely  large  geographic  area,  that  the  company  serves,  a  great 
deal  of  coordination  and  prioritizing  must  take  place  to  ensure  that  service  is 
maintained  and  restored  to  as  many  people  as  possible  in  the  shortest  amount  of  time. 
In  accomplishing  this  goal,  the  service  dispatcher  must  prioritize  daily  work 
schedules,  assign  jobs  to  field  units,  and  monitor  the  progress  of  all  field  workers. 
Additionally,  during  the  evening  hours,  the  service  dispatcher  becomes  the  only 
service  operator  on  duty,  increasing  the  amount  of  coordination  required. 


4.  Distribution  Operator 

The  distribution  operator  is  one  of  the  key  safety  coordinators  for  all  maintenance 
actions.  When  a  field  worker  needs  to  perform  maintenance  on  a  particular  section  of 
line,  the  distribution  operator  ensures  that  the  maintenance  is  performed  safely.  The 
operator  does  this  by  referencing  a  checklist  of  maintenance  steps  while  the  field 
worker  is  performing  the  maintenance.  While  doing  this,  s/he  must  also  make  sure 
that  the  power  to  the  effected  line  is  secured,  and  that  it  is  safe  for  the  field  worker  to 
proceed. 


5.  Grid 

What  is  commonly  referred  to  as  the  "grid"  is  in  fact  the  layout  of  all  the  electrical 
lines  throughout  the  city. 

The  power  grid  is  made  up  of  substations,  lines,  circuit  breakers,  switches  and  fuses. 
This  grid  is  in  turn  laid  over  a  map  of  the  geographic  area,  allowing  for  isolation  of 
individual  residences  or  businesses  that  may  be  experiencing  problems. 


6.  Switches  and  Fuses 

Substations  are  the  sources  for  the  power  that  goes  out  on  a  particular  line.  The  line, 
typically  21,000  volts,  carries  the  power  throughout  the  area  for  distribution.  Smaller, 
1000  volt  lines  feled  off  of  the  21  kilovolt  lines  and  step  down  to  distribute  electricity 
to  individual  residences  and  business.  On  each  of  these  high  and  low  power  lines  are 
circuit  breakers,  switches,  and  fuses.  These  devices  protect  the  equipment  from  surges 
and  underages  of  power,  which  can  cause  damage  to  vital  equipment. 


7.  Current  Switching  Method 
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During  a  global,  large-scale  outage,  workers  must  progressively  switch  on  and  off  the 
switches  within  the  system  in  order  to  isolate  where  the  problem  is  located.  Once  the 
problem  has  been  located,  only  then  may  work  proceed  in  order  to  restore  service. 
This  is  typically  a  very  time  consuming  endeavor,  requiring  a  great  deal  of 
coordination  and  manpower.  When  work  or  maintenance  needs  to  be  performed  on  a 
particular  line,  a  field  worker  must  go  out  to  the  circuit  breakers,  switches,  or  fuses 
directly  upstream  and  downstream  from  the  affected  piece  of  equipment,  and 
manually  switch  them  off  to  isolate  the  line.  Once  this  has  been  accomplished,  then 
work  on  that  line  or  piece  of  equipment  may  proceed. (Return  to  background 
information) 

8.  Intelligent  Switches  and  Fuses 

The  company  has  begun  to  replace  its  old  technology  switches  and  fuses  with  new, 
"intelligent"  switches  and  fuses.  These  new  devices  can  be  controlled  via  the 
telephone,  automatically  switching  on  or  off  when  receiving  the  appropriate  code. 
These  switches  are  denoted  on  the  power  grid  map  with  the  "TC"  code,  which  means 
telephone  controlled. 


3.2.  USING  REMAP  DURING  SYSTEM  ANALYSIS 

The  following  section  of  the  example  illustrates  REMAP's  use  during  the  system 
analysis  phase.  In  the  scenario,  the  analysts  are  engaged  in  a  deliberation  on  a 
requirement  for  processing  service  orders.  Three  issues  that  are  raised  by  the  team 
members  are: 

How  should  calls  be  handled? 

How  are  service  orders  prioritized? 

How  are  service  orders  tracked? 

The  deliberation  involves  verifying  alternatives  or  alternatives  that  solve  the  issues 
and  arguments  behind  them,  and  their  underlying  assumptions.  We  briefly  describe 
how  various  multimedia  segments  of  the  discussion  are  incorporated  in  the  design 
rationale  knowledge. 


1 .  Process  Service  Order  Information 

A  primary  requirement  is  that  the  system  should  be  able  to  handle  incoming  calls, 
establish  priorities  among  the  calls,  and  track  the  calls  once  they  have  been  answered. 
Many  customers  require  up  to  date  and  accurate  information  in  order  to  make 
important,  sometimes  life  or  death,  decisions.  For  example,  a  residential  customer 
may  be  reliant  on  an  electrically  operated  medical  device.  She  could  not  survive  for 
more  than  five  hours  without  this  device.  This  customer  needs  to  know  when  the 
power  will  be  restored,  so  a  decision  can  be  made  as  to  whether  or  not  to  move  to  a 
location  where  electricity  is  still  available. 

a.  How  Should  Calls  Be  Handled?  (Issue)  (Please  see  the  figure  below. ) 

The  primary  interface  between  the  company  and  the  customer  is  through  service  calls. 
Meeting  the  needs  of  the  customer  is  the  company's  main  goal,  and  achieving  this  can 
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best  be  accomplished  by  effectively  and  efficiently  handling  incoming  calls.  The  issue 
of  importance  here  is  how  to  handle  incoming  calls. 

i.  Human  Operator  (alternative) 

The  first  alternative  is  that  the  calls  should  ah  be  handled  by  a  human  operator,  who 
will  take  information  and  route  the  call  manually. 

ii.  Personal  Interaction  (Argument) 

The  operator  is  the  only  person  that  the  customer  will  interact  with.  Ah  of  the 
customer's  perceptions  about  the  company  are  based  on  their  experiences  with  the 
phone  operators.  For  this  reason,  human  operators  are  preferable  to  automated 
systems.  Computer  systems  cannot  provide  the  personal  touch  that  customers  prefer. 

iii.  Current  Answering  Methods  (Argument) 

The  current  system  of  call  handling  is  operator  interaction  with  the  customer.  An 
automated  system  would  add  costs  to  the  established  system,  and  would  degrade  the 
company's  public  image  both  among  its  employees  and  the  general  public. 

iv.  Computer  Routing  (alternative) 

Computer  routing  allows  the  customer  to  indicated  what  type  of  service  is  required 
before  having  to  talk  with  an  operator. 

v.  Voice  Mail  (Argument) 

A  voice  mail  system  would  allow  the  customer  to  leave  a  message  indicating  what 
type  of  service  is  required,  allowing  the  operators  to  handle  more  urgent  calls  directly. 

vi.  Time  Not  Critical  For  Calls  (Assumption) 

Most  calls  that  come  in  to  the  service  center  are  not  of  a  critical  nature.  By  using  a 
computer  routing  system  that  breaks  out  calls  by  their  type  (billing,  maintenance, 
service,  etc.),  operators  will  be  able  to  spend  more  time  handling  critical  calls. 
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Time  Not  Critical  For  Calls 


30 


b.  How  frequently  should  orders  be  processed  (issue),  and  How  they  are  to  be 
prioritized  (issue)? 

i.  Process  Order  (Requirement) 

The  utility  is  considering  the  requirement  to  process  service  orders  placed  by  its 
customers  for  various  kinds  of  services.  This  requirement  raises  the  above  two  issues  . 

The  issue  of  prioritizing  orders  is  very  critical  to  meeting  a  variety  of  objectives 
related  to  processing  orders  and  is  considered  to  be  worthy  of  a  serious  discussion. 
Three  alternative  ways  of  prioritizing  orders  is  discussed  by  the  design  team. 

ii.  Location  (alternative) 

One  suggestion  is  to  pull  together  all  orders  that  are  from  a  given  geographical 
location  or  area. 

iii.  Economical  (argument) 

The  above  alternative  is  supported  by  the  argument  that  grouping  orders  originating 
from  the  various  areas  serviced  by  the  company  is  the  most  economical  way  to  process 
orders. 

i.v.  Large  service  area  (assumption) 

The  above  argument  is  based  on  the  assumption  that  the  company  is  servicing  a  very 
large  geographical  area  and  therefore,  its  needs  can  not  afford  to  dispatch  multiple 
teams  to  diverse  locations  within  cost  and  time  constraints. 

v.  Customer  type  (alternative) 

The  second  alternative  proposed  by  a  member  of  the  design  team  is  that  orders  can  be 
prioritized  based  on  the  type  of  customer  being  serviced.  For  example,  all  requests 
originating  from  hospitals  will  be  treated  with  higher  urgency  compared  to  those 
coming  from  residential  customers. 

vi.  Prompt  service  (argument) 

The  above  alternative  is  supported  by  the  argument  that  it  is  essential  to  provide 
prompt  service  to  certain  types  of  customers  (e.g.,  hospitals,  industrial  customers  with 
power  critical  processes).  This  argument  is  based  on  two  underlying  assumptions. 

vii.  Versatile  crew  (assumption) 

One  critical  assumption  is  that  the  company  employs  a  crew  that  is  trained  to  handle 
all  kinds  of  requests  that  may  originate  from  the  various  customer  segments. 

viii.  Similar  needs  for  all  customers  (assumption) 

The  argument  will  also  depend  on  the  assumption  that  all  customers  (within  a 
customer  segment  like  residential  customers)  have  similar  needs.  For  example,  if 
some  residential  customers  also  have  life-saving  medical  equipment  then  treating 
them  as  other  residential  customers  will  be  disastrous  (i.e.,  will  make  this  assumption 
untrue). 

ix.  Service  type  (alternative) 

The  third  alternative  proposed  by  the  design  team  is  to  combine  all  orders  for  a 
specific  service  (i.e.,  outages,  turning  off  service  etc.). 
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x.  Easy  processing  (argument) 

The  above  alternative  is  supported  by  the  argument  that  it  is  the  easiest  way  to  process 
customer  orders. 

xi.  High  processing  time  (assumption) 

The  above  argument  is  based  on  the  assumption  that  processing  service  orders  of 
different  kinds  together  will  take  lot  of  time  for  the  crew  compared  to  handling  the 
same  kinds  of  problems  for  various  customers. 

xii.  Current  implementation  (assumption) 

The  argument  that  it  is  the  easiest  scheme  to  implement  is  also  based  on  the 
assumption  that  it  is  the  scheme  currently  in  use  and  therefore  will  be  the  easiest  to 
follow. 

xiii.  Select  Customer  type  (Decision) 

The  decision  arrived  at  by  the  design  team  is  to  go  with  a  scheme  that  appears  to 
provide  the  most  effective  service  to  the  customers.  This  decision  selects  the 
alternative  Customer  type. 


c.  How  Are  Service  Orders  Tracked?  (Issue)  (Please  see  the  figure  below. ) 

The  status  of  all  service  calls  must  be  tracked  and  updated,  to  allow  for  timely 
customer  notification.  How  these  calls  should  be  tracked  is  the  issue. 

i.  CURRENT  METHODS  (alternative) 
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Currently,  all  calls  are  manually  tracked  by  placing  follow-up  calls  for  every  service 
tag  generated.  This  method  guarantees  that  all  customers  are  given  return  calls 
updating  them  on  the  status  of  their  service. 

ii.  MANUAL  TRACKING  (Argument) 

The  current  method  of  tracking  orders  is  satisfactory,  and  performs  well. 

iii.  COMPUTER  STORAGE  (alternative) 

A  database  system  of  call  storage  should  be  implemented  to  help  track  orders. 

iv.  AUTOMATED  TRACKING  (Argument) 

The  new  system  should  store  calls  on  a  centralized  database  without  actually 
generating  the  tags.  When  service  has  been  restored,  the  computer  should  be  able  to 
automatically  dial  the  customer  back,  and  let  the  operator  update  the  customer.  This 
will  greatly  reduce  the  time  demands,  because  the  tags  will  not  have  to  be  manually 
sorted  and  rechecked. 


Manual  Tracking 


3.3.  USING  REMAP  IN  THE  DESIGN  PHASE 

The  following  is  an  example  use  of  REMAP  during  the  design  phase  of  system 
development.  During  this  phase,  the  development  team  is  engaged  in  discussions 
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concerning  the  specific  design  mechanisms  to  process  service  tags.  The  issues  being 
considered  are: 

How  to  get  customer  records? 

How  should  the  service  operator's  screen  be  organized? 

How  should  service  tags  be  screen  ?. 

These  deliberations  identify  and  solve  issues  concerning  the  design  phase  of  the 
project.  Included  in  this  section  are  descriptions  of  how  the  multimedia  segments  are 
incorporated. 

1.  Process  Service  Tags 

Automating  the  processing  of  the  service  tags  should  provide  the  company  with  the 
following  information: 

Grid  customer  is  on. 

Feeder  Number  of  customer. 

Is  this  an  isolated  event  or  a  global  outage? 

It  is  required  that  the  system  show  that  it  can  provide  the  above  information  faster  and 
with  fewer  people  involved  in  the  process. 


a.  How  to  Get  Customer  Record?  (Issue)  (Please  see  the  figure  below.  ) 

A  customers  record  contains  a  variety  of  information.  Customer  address,  phone 
number,  and  account  number  are  the  basics.  Included  in  the  record  is  what  grid  the 
customer  is  on,  the  feeder  number,  maintenance  historical  records,  as  well  as  all 
billing  information.  Some  of  this  information  is  added  to  the  newly  generated  tag.  The 
issue  is:  How  should  the  customers  record  be  retrieved? 

i.  Entire  Record  (Position) 

The  entire  record  should  be  retrieved  by  the  customer  service  operator  at  the  time  of 
the  phone  call.  If  a  service  tag  is  to  be  generated  by  the  call,  the  appropriate 
information  will  be  added  to  the  tag  at  that  time.  The  operator  will  be  able  to  verify 
the  correctness  of  the  address  as  well. 

If  the  call  is  a  request  for  billing  information,  it  can  be  handled  at  that  time.  All  of  the 
customer's  information  is  already  there.  Not  all  of  the  information  need  be  displayed  at 
all  times.  The  operator  should  have  the  ability  to  "drill  down"  to  more  detailed 
information  as  it  is  needed.  For  this  reason,  the  information  should  be  retrieved  and 
ready  to  display  for  whatever  the  situation  is. 

ii.  Better  Customer  Relations  (Argument) 

When  a  customer  calls  in,  the  call  is  posted  on  the  Call  Status  Board.  The  operator  has 
no  idea  of  what  the  customer  is  calling  about  until  she  gathers  more  information. 
Because  the  operator  is  the  main  interface  between  the  company  and  the  customer,  the 
operator  should  have  quick  and  ready  access  to  all  of  that  customer's  information.  At 
any  given  time,  the  customer  could  be  calling  about  a  billing  problem,  a  power  outage, 
or  a  maintenance  problem.  For  this  reason,  the  operator  needs  to  be  able  to  instantly 


34 


retrieve  each  of  these  types  of  data.  The  most  efficient  and  expedient  way  of  doing 
this  is  to  retrieve  the  entire  record  as  soon  as  the  call  is  taken. 

iii.  Good  Public  Relations  (Assumption) 

Good  public  relations  is  important  in  this  industry  due  to  constantly  increasing  costs. 
The  operators  are  the  primary  communicators  and  representatives  for  the  company, 
and  hence  must  be  capable  of  handling  nearly  any  situation  that  could  arise  over  the 
phone. 

iv.  Fill  In  Name  And  Address  Of  Customer  (Position) 

If  a  service  tag  is  to  be  generated  from  this  call,  the  information  for  the  tag  can  be 
obtained  during  the  tag  processing,  not  during  the  phone  call.  Only  the  name,  address, 
and  phone  number  of  the  customer  are  needed  and  these  can  be  obtained  by  the 
operator  at  that  time.  If  there  is  a  billing  problem,  then  just  the  billing  information  of 
the  customer  needs  to  be  retrieved. 

v.  Faster  Process  (Argument) 

By  not  having  to  retrieve  the  entire  customer  record  every  time  a  phone  call  comes 
into  the  service  operator  center,  more  calls  can  be  handled,  providing  better  service  to 
the  customer. 
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Process  Service  Tags 


generates 


b.  How  Should  The  Service  Operator  Screen  Be  Organized?  (Issue)  (Please  see  the 
figure  below. ) 

Do  the  computer  interfaces  used  by  service  operators  need  to  be  redesigned  to  better 
streamline  the  new  automated  process? 

i.  Categories  For  The  Operator  To  Choose  From  (Alternative) 

The  screen  used  by  the  service  operators  should  have  a  list  of  9  to  10  categories  for 
the  operators  to  classify  a  maintenance  request  under. 

ii.  Current  Tag  Setup  9-10  Categories  For  The  Operator  To  Choose  From  (Argument) 

Ninety  nine  percent  of  all  problems  fall  under  these  specified  categories.  The 
maintenance  people  will  not  use  any  more  information  than  the  basics  anyway.  This  is 
also  the  current  interface  setup.  No  new  training  required. 

iii.  Operator  Fill  In  Text  (Alternative) 

The  screen  should  have  the  basic  address  information  for  the  operator  to  confirm 
correct.  Then  have  a  text  box  for  the  service  operator  to  type  in  a  description  of  the 
problem.  This  will  allow  for  precise  descriptions  of  the  problem,  reducing  the 
troubleshooting  time  required  by  the  field  workers. 

iv.  More  Information  (Argument) 
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The  more  information  describing  the  problem  on  the  tag  will  help  the  maintenance 
people  understand  the  problem  better  before  actually  talking  to  the  customer 
themselves. 

v.  Good  Typists  (Assumption) 

All  the  service  operators  are  good  typists,  so  this  will  not  slow  the  process  down  any. 

vi.  One  Sized  Text  Box  (Assumptions) 

One  set  sized  text  box  will  be  able  to  handle  any  description  made  by  a  customer. 


c.  How  Should  The  Service  Tags  Be  Screened?  (Issue)  (Please  see  the  figure  below.  ) 

The  manual  screening  process  that  is  used  currently  is  just  too  slow.  This  process  must 
be  automated.  Each  tag  will  have  on  it  the  customers'  grid  number,  as  well  as  source 
side  device  tag  number.  The  database  must  be  able  to  screen  the  tags  and  sound  an 
alert  if  there  seems  to  be  a  global  outage  occurring. 

i.  Screen  All  Tags  Generated  In  The  Last  30  Minutes  (Alternative) 

If  a  tag  for  a  complete  electrical  failure  is  generated,  it  needs  to  be  compared  to  any 
tag  with  a  similar  complaint  to  determine  if  this  is  an  isolated  event  or  not.  If  not,  then 
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there  is  a  possibility  of  a  global  failure.  One  method  suggested  to  determine  this 
would  be  to  compare  the  tag  to  those  tags  generated  in  the  last  30  minutes. 

ii.  Fewer  Tags  Generated  (Argument) 

This  comparison  will  allow  fewer  tags  to  be  generated  if  there  is  a  global  outage. 

iii.  Last  10  Tags  (Alternative) 

Power  failure  tags  need  to  be  compared  with  the  last  1 0  tags  regardless  of  time  in 
order  to  detect  a  global  failure. 

iv.  Easier  Method  (Argument) 

This  is  an  easier  method  to  implement  and  it  gets  the  same  job  done.  Fewer  tags  will 
be  generated. 
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Appendix  2:  REMAP  Legend 

The  following  diagram  illustrates  the  Icons,  their  interrelations: 
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